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ABSTRACT 


Organizations have traditionally relied on paper to conduct business 
transactions. Although proven to be an effective and convenient medium for this 
purpose, paper may no longer be the most efficient. Advances in computers, 
communication, and electronic technology have provided alternatives to this 
traditional way of conducting business transactions. One such concept is 
Electronic Data Interchange (EDI), which allows information to be processed 
faster, more accurately, and at a lower cost than similar manual, paper-based, 
processing systems. This thesis examines the application of EDI to Defense 
transportation operations and includes a discussion of data format standards, 
hardware, software, and communications requirements. The Defense 
transportation EDI operating concepts involve the linking of carriers, MTMC, 
defense shipping activities, and DoD finance centers, which allows the electronic 
exchange of business data such as Government bills of lading, freight rate tenders, 
and carrier payment information. EDI involves more than simply automating 
existing business documents and processes; when properly implemented, EDI is 
a catalyst for streamlining inefficient, redundant, and outdated business practices. 
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I. INTRODUCTION 


A. BACKGROUND 

Electronic Data Interchange (EDI) is rapidly emerging as 
the preferred method for conducting transactions involving the 
exchange of "business information." As one industry analyst 
predicted: [Ref. l:p. 45] 

By the end of this decade, EDI no longer will be a 

competitive tool that differentiates one company from 

another. It will be a business necessity for survival. 

Public and private organizations, including civilian as 
well as military components, have traditionally relied on 
paper to conduct business transactions. Although paper has 
proven to be an effective and convenient medium for this 
purpose, for many situations it may no longer be the most 
efficient. Advances in computer, communication, and 
electronic technology have provided alternatives to the 
"traditional" ways of conducting business. Recent examples of 
technological advancements which have produced changes in the 
manner in which information is handled include: 

• Cellular and mobile telephones 

• Photocopying machines 

• Personal computers 

• Facsimile machines 
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Each of these applications has taken an existing process, 
or way of doing things, and "made it easier" and more 
efficient. 

Today, especially with both the public and private sectors 
experiencing diminishing budgetary resources, organizations 
are continuing their search for ways to "do more with less." 
One concept that has demonstrated considerable promise is that 
of Electronic Data Interchange (EDI). 

The use of EDI technology is becoming more common in many 
organizations and promises to become the preferred method for 
exchanging information in the future. Through the use of 
electronic information processing techniques, EDI enables 
information to be processed faster, more accurately, and at a 
lower cost than with similar manual, paper-based, processing 
systems. 

When discussing the application of electronic data 
interchange, it is important to understand that EDI is a 
technology, a way of doing business, and not a specific 
system. The implementation of EDI involves more than just the 
automation of existing processes. Electronic data interchange 
provides the opportunity to revise existing information 
handling methods which can result in improved performance, 
economies, and efficiencies in operations. 

Recognizing the potential of EDI, the Deputy Secretary of 
Defense, in May of 1988, issued a memorandum that EDI was to 
"become the way of doing business” for zr.e Department of 
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Defense (DoD). In November 1990 the Deputy Secretary of 
Defense approved Defense Management Report Decision (DMRD) 
941, which directed the development, implementation, and 
management of a standard DoD EDI system. 

The strategic goal of DoD's current EDI efforts is to 
provide the capability to initiate, conduct, and maintain the 
external and internal business - related activities utilizing 
electronic media. 

B. OBJECTIVES 

The primary objective of this thesis is to examine the 
application of electronic data interchange to Department of 
Defense transportation operations. 

A secondary objective is to provide an explanation of EDI 
fundamentals including: 

• What EDI is. 

• What the components of EDI are. 

• EDI system configurations, 

C. RESEARCH QUESTIONS 

To achieve the primary objective of the research, the 

following research question is posed: 

What actions have been taken to implement electronic data 
interchange with Department of Defense transportation 
operations? 

To answer the basic research question, the following 
subsidiary questions are addressed: 
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• What are the essential elements of EDI? 


• What has been the Department of Defense's approach to the 
implementation of EDI technology? 

• What benefits may be realized from DoD's EDI 

implementation with defense transportation operations? 

• What are the specific areas in which EDI has been applied 
to DoD transportation? 

• What are the proposed defense transportation EDI 
application areas? 

• What, if any, barriers exist to the optimal implementation 
of EDI? 


D. SCOPE 

The scope of this thesis focuses on the following primary 
areas: 

• Providing an overview of EDI, to include a discussion of 
the necessary elements. 

• Discussion of DoD EDI implementation. 

• An examination of EDI application to DoD transportation 
operations. 

Throughout this thesis, it is assumed that the reader has 
some familiarity with defense transportation activities and 
operations. Additionally, this thesis is structured to 
provide those not familiar with electronic data interchange a 
basic understanding of its concept and operation. 

E. METHODOLOGY 

The methodology used to complete this thesis consisted of 
literature reviews as well as research involving interviews 
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with appropriate Department of Defense, Defense Logistics 
Agency, General Services Administration, Army, Air Force, 
Navy, Marine Corps, and Logistic Management Institute 1 
representatives. This enabled the author to determine where 
the Department of Defense objectives are focused and to what 
extent they have been instituted and implemented. 

F. DEFINITIONS AND ABBREVIATIONS 

A list of acronyms used within this thesis is presented in 
Appendix A. Working definitions of terms and concepts used in 
this thesis will be provided within the text of the thesis as 
deemed necessary. 

G. ORGANIZATION OF STUDY 

This thesis is organized to provide the reader with an 
overview of EDI and its application to defense transportation 
operations. Chapter II provides the reader with an overview 
of electronic data interchange, including: what it is, its 
purpose, historical background, potential benefits, and 
emerging issues. 

Chapter III discusses EDI data format standards and their 
importance to EDI communications. This chapter also discusses 
implementation conventions, which are guidelines for the 
standardized use of the data format standards. 


1 The Logistics Management Institute is a federally funded 
research and development center that performs specific studies for 
DoD. 
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Chapter IV contains a discussion of the architecture of 
EDI application and covers required hardware, software and 
communication connections. 

Chapter V discusses the overall Department of Defense 
approach to EDI implementation and introduces significant 
policy milestones which have encouraged EDI's acceptance 
within DoD. 

Chapter VI contains the examination of DoD's application 
of EDI to defense transportation activities. 

Chapter VII provides the reader with a summary and 
presents the author's conclusions. 
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II. ELECTRONIC DATA INTERCHANGE OVERVIEW 


Properly planned and implemented EDI has the potential 
to restructure markets, re-engineer inefficient manual 
processes, open up access to new customers, streamline 
flow of materials throughout an entire value chain, 
enhance quality across the board, and save millions of 
dollars. (Thomas P. Colberg, Price Waterhouse) 

Communication and information are vital components of most 
of the activities in which organizations engage. In many 
cases they are the primary determinants in decision making, 
with information consisting of the facts, figures, and 
knowledge, while communication is the means of conveying this 
information from those who possess it to those who require it. 
Recognizing the importance of communication and information, 
organizations are continually looking for ways to improve the 
efficiency and effectiveness of their communication and 
information handling processes. The past few decades have 
produced an astonishing array of advances in the methods by 
which information is handled: 

• Photocopying machines 

• Cellular and mobile telephones 

• Facsimile machines 

• Personal computers 

• Electronic mail (E-mail) 

• Electronic data interchange 

• Teleconferences 
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• Overnight document delivery services 


With this ever increasing assortment of communication and 
information processing techniques, it is important to 
establish what electronic data interchange (EDI) is. To 
understand the true potential and significance of EDI it must 
be remembered that EDI is a technology, an approach to doing 
things, rather than a specific system. 


A. ELECTRONIC DATA INTERCHANGE DEFINITION 

Electronic Data Interchange is the inter-organizational, 
computer-to-computer exchange of business documentation and 
information in a standardized, machine-processable format. 
[Ref. 2:p. 4] 

This definition of EDI contains a number of key points 
which distinguish it from other forms of paper or electronic 
communication: [Ref. 2:pp. 4-5] 

• Inter-organizational: While EDI technology is equally 
applicable to exchanging information within organizations, 
by definition EDI is organization-to-organization. 

• Computer-to-computer: Once the data is entered into the 
originator's application, the information flows directly 
to the receiver's application. The key point is that once 
entered, the data flows between organizations without 
human intervention and without paper. 

• Business Documentation: Information that is currently 

found on any business form is appropriate for EDI. 
Examples of typical business documents which are exchanged 
electronically include: purchase orders, invoices, bills 
of lading, status reports, receipt acknowledgements, and 
payment information. 
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• Standardized, Machine-processable Format: As discussed, 
EDI is the electronic exchange of information from one 
computer to another without human intervention. For this 
to occur the data must be precisely formatted to allow 
computers to both read and understand the information. 

B. PURPOSE OP ELECTRONIC DATA INTERCHANGE 

The primary purpose of EDI is to provide the opportunity 
to make business processes more efficient by enhancing 
information management through the replacement of paper with 
electronic equivalents. This is accomplished through the use 
of established "standards" which provide the required 
structured format (language), allowing direct data 
transmission from one organization's computer to another 
organization's computer without human intervention. The basic 
functioning of EDI, compared to a "traditional paper-based" 
system, is shown in Figure 1 and Figure 2. 

As shown in Figure 1, the originating organization creates 
a "document" when data is initially entered into its computer 
system. For the receiving organization to obtain and use this 
information the "document" will be printed, physically 
transferred (in this example by mail), and finally the data 
must be manually entered into their computer system. In 
contrast. Figure 2 illustrates the direct transmission of data 
computer-to-computer, requiring human intervention only for 
the initial data entry. 
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_ Originating Organization Receiving Organization _ 

Figure 1. Example of a traditional paper-based method of 
exchanging information 
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Figure 2. Example of an EDI-based information exchange 
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C. BACKGROUND OF ELECTRONIC DATA INTERCHANGE 
1. The Historical Emergence o£ Standards 

Computer-to-computer exchange of information is not 
new to American industry or to the Department of Defense 
(DoD). Since the 1960s, private companies and DoD activities 
have been exchanging business information electronically. A 
major characteristic, and drawback, of these early data 
exchange arrangements was the use of many different non¬ 
standard and proprietary data formats. 

Prior to the development of standard data formats, 
organizations may have needed different computer systems or 
applications for each customer, or trading partner, with which 
it wished to electronically communicate. This in turn 
hindered the widespread acceptance of EDI, with organizations 
finding it cumbersome, time-consuming, and often expensive to 
expand their electronic communications to new trading 
partners. 

The development of standard data formats played an 
important role in the development of EDI technology. 
Standardization eased the exchange of data and encouraged the 
use of EDI technology by eliminating the need to create 
special software for each trading partner's unique data 
format. 

Standard data formats allow one software package to be 
used to generate transactions in a format allowing for the 
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exchange of information between multiple trading partners. By 
reducing the software requirements for exchanging information, 
standards help reduce the cost of new technology 
implementation, increasing the benefits to users by providing 
a common language between trading partners which may be in 
different industries. [Ref. 3:pp. 3-4] 

Early standards development occurred in the 
transportation industry in the mid 1970's, when the 
Transportation Data Coordinating Committee (TDCC) developed 
industry-specific standards for ocean, motor, air, and rail 
carriers [Ref. 4:p. 6]. When this effort proved successful, 
other industries sought the help of TDCC in developing 
standards for their industries 2 . As the number of industry- 
specific standards grew, recognition of the need for generic, 
cross-industry standards emerged [Ref. 5:p. 2]. 

In 1979, in response to the growing concern over the 
development of cross-industry standards, the American National 
Standards Institute (ANSI) chartered the Accredited Standards 
Committee X12 (ASC X12) to develop uniform standards to 
facilitate the electronic interchange of business transactions 
between and among industries [Ref. 4:p. l]. The ASC X12 
standard is the only set of standards approved by the American 
National Standards committee and are quickly becoming the only 


2 Examples of some of the industry-groups seeking the help of 
TDCC include: the grocery, chemical, and warehousing industries 
[Ref. 5:p. 2]. 
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universally recognized standards for the electronic 
transmission of business data [Ref. 3:p. 60], 

2. American National Standards Institute and the 
Accredited Standards Committee X12 

Founded in 1918, The American National Standards 
Institute (ANSI) is a private organization which has been a 
significant contributor to the development of EDI, serving as 
a clearinghouse and information center for American National 
Standards as well as international standards. ANSI is 
recognized as the central body responsible for the 
identification and coordination of the development of a 
single, consistent set of voluntary standards called American 
National Standards. ANSI provides a democratic, consensus- 
based forum for all concerned to identify standards 
requirements, to plan to meet those requirements, and to agree 
on standards. ANSI does not develop standards but is 
responsible for the approval of standards which have been 
developed by professional societies, trade associations, and 
other organizations. [Ref. 4:p. l] 
a. A SC X12 Organization 

As mentioned previously, in 1979 ANSI chartered the 
Accredited Standards Committee (ASC) X12 in response to the 
growing concern over the development of cross-industry 
standards. As with ANSI, ASC X12 is a private organization 
with membership open to any individual, company, or 
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organization which has an interest in ASC X12 activities and 
standards development. 

The primary objective of ASC X12 is to develop 
uniform standards to facilitate the electronic interchange of 
business transactions between, and among industries [Ref. 4:p. 
1]. As stated in the ASC X12 charter: 

The scope of X12 is to provide standardization to 
facilitate interbusiness/institutional electronic 
interchange of transactions relating to order placement 
and processing; shipment and receiving information; 
invoicing; payment; and cash application date. [Ref. 3:p. 

51] 

The ASC X12 organization is composed of two 
overview committees as well as a number of subcommittees and 
task groups. The ASC X12 organization is structured as shown 
in Figure 3. [Ref. 4:p. 2] 

(1) ASC X12 Overview Committees. The two overview 
committees are the Steering Committee and the Procidures 
Review Board. These committees are responsible for the 
following: [Ref. 2:p. 63] 

• Steering Committee performs administrative functions for 
ASC X12 and provides coordination among task groups and 
subcommittees. 

• Procedures Review Board (PRB) reviews all project 
proposals submitted to the committee. The PRB also 
manages draft standards, standards maintenance, and 
compliance guidelines. 

(2) A SC XI2 Subcommittees and Task Groups. The 
actual work of ASC X12 is conducted primarily by the 
subcommittees and task groups, who are responsible for the 
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Figure 3. ANSI ASC X12 organization 























development of new, and the maintenance of existing, ASC X12 
EDI standards. The subcommittees primarily focus on 
functional areas such as transportation, finance, purchasing, 
technical assessment, etc. Supporting the subcommittees and 
the Steering Committee are the task groups which focus on 
specific issues such as legal and organizational procedures. 
The recommendations of the subcommittees and task groups are 
presented to the ASC X12 membership for formal acceptance and 
ratification. [Ref. 6:pp. 1-2] 

(3) Data Interchange Stemdards Association, Inc 
(DISA ). DISA is a not-for-profit corporation, formed in 1987, 
to serve as ASC X12 secretariat. DISA staff provides 
administrative support for ASC X12 including management of ASC 
X12 membership, balloting, standards development and 
maintenance, publications, and communications with ANSI on 
behalf of ASC X12. [Ref. 6:p. 1] 

Jb. ASC XI2 Standards Approval 

Any individual or organization, whether a member of 
the ASC X12 committee or not, can request that a new standard 
be developed or that an existing standard be modified. Such 
a request is usually submitted to the secretariat (DISA) who 
forwards the request to the Technical Assessment Subcommittee 
(X12J), as depicted in Figure 4. [Ref. 4:p. 5] 

The Technical Assessment Subcommittee is 
responsible for assessing whether or not the request for a new 
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or modified standard is within the scope of ASC X12. If it is 
determined to be within scope, the Technical Assessment 
Subcommittee forwards the request to the applicable functional 
area subcommittee for review. Based on the request, the 
functional area subcommittee prepares a formal project 
proposal which is returned to the Technical Assessment 
Subcommittee for a consistency check with other standards. If 
the proposal is successful in passing this check, it is sent 
to the Procedure Review Board for an additional vote on 
whether the proposal is within the scope of ASC X12 and 
consistent with existing standards. If the proposal passes 
this vote it is referred back to the original functional area 
subcommittee for actual standards development. This 
subcommittee is then responsible for preparing the draft 
standard (proposed) , which will in turn be subject to a 
technical assessment review as well as a Procedures Review 
Board check. Next, the proposed draft standard is distributed 
to all ASC X12 committee members for review, comment, and 
vote. After a review of the vote and comments, the proposed 
draft standard is sent to the Procedures Review Board for a 
vote on releasing the proposed draft standard. If the vote is 
in favor of release, the draft proposed standard is designated 
an ASC X12 draft standard, and is released for trial use. The 
ASC X12 draft is not yet a fully approved standard, still 
requiring ANSI approval. Once received by ANSI, the ASC X12 
draft standard is again distributed for public review and 
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comment. It is only after the completion of this public 
process that the standard is approved and released by ANSI as 
an American National Standard (ANS) 3 . [Ref. 2:pp. 64-65] 

D. BENEFITS OF ELECTRONIC DATA INTERCHANGE 

Through the use of electronic, vice paper-based systems, 
EDI results in a more efficient and effective way to conduct 
business transactions. Primarily, the use of EDI decreases 
the transaction time associated with document/information 
handling while increasing the accuracy of the information 
exchanged. There are many possible and potential benefits 
from the implementation of EDI. Some of these are "more 
obvious" and easily quantifiable, while others are "less 
obvious" and more qualitative in nature. While the actual 
realized benefits will be situationally dependent, a majority 
of the benefits of EDI implementation will fall under one of 
the following categories: 

• Savings 

• Accuracy 

• Speed 


3 It is important to note that compliance with ANSI approved 
American National Standards is strictly voluntary. Though not 
having the force of law, the standards provided a common, accepted 
format for the electronic exchange of information. 
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1. Savings 

EDI eliminates, or reduces, the volume of paperwork 
required to conduct many standard business transactions. With 
this paperwork reduction comes a corresponding reduction in 
mailing and postage costs, along with costs associated with 
the personnel and equipment required to manually process 
paper-based transactions. 

2. Accuracy 

Many non-EDI information processing systems are 
characterized by a data entry/re-entry cycle in which the same 
data is entered and re-entered numerous times. EDI eliminates 
this re-entering of data by exchanging data directly between 
computer systems. This direct exchange of data reduces the 
possibility of data errors which can result from repeated 
"handling" and human intervention. 

3. Speed 

With non-EDI information processing systems, the 
process of exchanging data is often slow, resulting from a 
reliance on mail, courier service, facsimile machines, or even 
telephone. EDI dramatically decreases the time spent 
exchanging data between users by the virtually instantaneous, 
computer-to-computer, transmission of information 
electronically.. 

The proper implementation of EDI results in the ability to 
conduct business faster, more accurately, and at a lower cost 
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than similar manual, paper-based information processing 
systems. 

B. EMERGING ISSUES 

The implementation of EDI brings with it its own set of 
concerns. As discussed, EDI involves the reduction, or 
elimination, of much of the paperwork involved in conducting 
business transactions. Consequently, the affected process 
moves from an environment which relies on tangible paper 
documents to one which could be characterized as relatively 
intangible, where the documents are composed of electronic 
bits and bytes. Although EDI has many advantages over paper- 
based systems care must be taken, as it must with paper 
documents, to ensure that EDI messages are authentic, properly 
authorized, and traceable. The messages also must be 
protected from loss, modification, or unauthorized disclosure 
during transmission as well as storage. These concerns can be 
grouped into the following three categories: 

• Auditing 

• Legal 

• Security 

1. Auditing 

In an EDI system, as with any system used to process 
business transactions, the need exists for the ability to 
verify that the system is processing information correctly, as 
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well as processing the "correct" information. As in paper- 
based systems, verification is provided by the capability to 
track transactions from origination to closure. This tracking 
of the transaction through the system is referred to as the 
"audit trail". [Ref. 3:p. 47] 

The key to EDI auditability is having adequate 
controls to insure proper transaction handling. The control 
mechanisms for an EDI system should address accuracy, 
completeness, security, auditability, timeliness and 
recoverability issues. Additionally, controls relating to the 
use of EDI networks and Electronic Funds Transfer (EFT) should 
be included where appropriate. [Ref. 2:p. 179] 

The use of EDI, or any other automated system, from an 
auditing viewpoint has no effect on the need to follow 
generally accepted auditing standards and procedures. 
Although EDI may change the way in which organizations conduct 
business transactions, the use of EDI does not limit 
auditability. [Ref, 2:p. 179] 

2. Legal 

EDI is used to exchange data relating to many types of 
business transactions, many of which are intended to form 
legally binding contracts between parties. It is when EDI is 
used as the basis for forming a contract, or any legally 
binding agreement, that the majority of the legal issues 
emerge. These issues primarily concern items such as 
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enforceability, signature requirements, and terms *nd 
conditions, areas in which paper documents were inherently 
part of transaction. In response to these concerns, two 
primary areas emerge as requiring comment: [Ref. 2: pp. 169- 
173] 

• Trading Partner Agreements (TPA) 

• Electronic Signatures 

a. Trading Partner Agreements 

One way to deal with legal issues concerning the 
conduct of business through EDI is by the use of Trading 
Partner Agreements. Trading Partner Agreements (TPAs) are 
written, negotiated instruments of understanding which 
establish the rights and obligations, as well as create 
legally binding obligations between trading partners. When 
establishing TPA's, a separate document must be negotiated 
between each pair of trading partners and signed prior to 
initiating EDI transactions. [Ref. 2:p. 172] 

Trading Partner Agreements accomplish two primary 
purposes: 1) they establish the contractual relationships and 
references between trading partners (terms of conducting 
business), and 2) they specify the EDI technical protocols 
that will be used in conducting business through EDI-based 
transactions. In establishing the foundation for conducting 
business through EDI, TPAs provide clarification of various 
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technical and telecommunications issues associated with EDI 
business information exchange such as: [Ref. 7:pp. 5-6 - 5-7] 


• The applicable EDI implementation guidelines. 

• Telecommunications mailbox addresses and routings for each 
trading partner. 

• Schedules for transmitting messages. 

• Procedures for resolving transaction and system errors. 

• Back-up procedures in the event of system failure. 

• The electron! recordkeeping responsibilities of each 
tradi:.' parte 

• The password generation and security methods that each 
trading partner will use. 

By addressing these types of concerns upfront, TPAs 
help reduce future disputes concerning the "legality" and 
applicability of EDI transactions. 
b. Electronic Signatures 

Contracts are typically considered valid only when 
signed by the parties involved. Performing transactions 
electronically, EDI eliminates the physical document which in 
the past was "signed" by the trading partners. These 
signatures were important because they signified the intent to 
be bound by, and to comply with, the terms of the contract. 
An amendment to Title 41 of the Code of Federal Regulations, 
Part 101-41 (41 CFR 101-41) specifically addresses this 

concern and authorizes the use of electronic signatures in the 
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transportation industry provided chey are authenticated. That 

regulation, in part, reads: [Ref. 8] 

Electronic Data Interchange (EDI) means the electronic 
exchange of transportation information by means of 
electronic transmission of the information in lieu of the 
creation of a paper document.... Signature, in the case of 
an EDI transmission, means a discreet authenticating code 
intended to bind parties to the terms and conditions of a 
contract. 

3. Security 

In June 1991 the National Institute of Standards and 
Technology published a Computer Systems Laboratory (CSL) 
Bulletin on computer systems technology, which provided 
explicit guidance on EDI security. Specifically, it directed 
that activities implementing EDI should attempt to satisfy the 
following security requirements: [Ref. 7:pp. 5-2 - 5-3] 

• Message Integrity: The transmitting activity must ensure 
that all critical information transmitted is received 
unchanged. 

• Confidentiality: Activities must restrict access to EDI 
transactions that contain personal, trade-secret, or 
sensitive data. 

• Originator Authentication: The receiving activity must 
have assurance that the EDI message was transmitted by the 
indicated originator. 

• Nonrepudiation: Those activities establishing EDI systems 
must ensure that binding proposals submitted by any of the 
trading partners cannot be denied. 

• Availability: All activities must develop back-up 

procedures for the protection of important data in case of 
systems failure. 


The security of electronic data is of significant 
importance for both users and auditors, who want assurances 




that EDI data are protected against unauthorized disclosure or 
modification during transmission, processing, and storage. 
When analyzing the security requirements of an EDI system, it 
is important to remember that not all EDI data need to be 
secured. If the data were not given extra security when using 
paper transactions, they probably do not require extra 
security in an EDI environment. [Ref. 2:p. 180] 

For those data identified as requiring extra security, 
cryptographic security may be used. Currently two types of 
cryptographic security are supported by the X12 standard and 
in use for EDI data: [Ref. 2:p. 180] 

• Encryption 

• Authentication 

a. Encryption 

Encryption involves the coding of a normal message 
into garbled form which cannot be read until it is decoded 
back to its original form. When using encryption, the 
originator of a message uses a special data encryption 
standard (DES) algorithm to transform readable text into 
unreadable coded text. The unreadable coded text is then 
transmitted to the receiving activity who must use the same 
DES algorithm to decode the message. Encryption protects the 
message from unauthorized disclosure since only those with the 
appropriate "key" can decipher the message. [Ref. 2:p. 180] 
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b. Authentication 

Where encryption protects the secrecy of the data, 
authentication protects its integrity, making any modification 
of the data obvious to the receiver. With authentication, 
both the originating and receiving activities have 
encryption/decryption keys. A DES algorithm is applied to the 
EDI message and originator's key to produce a message 
authentication code (MAC) that is unique to that message-key 
combination. The MAC is appended to the message and 
transmitted, along with the key identifier, to the receiver. 
To authenticate the message, the receiver uses the DES 
algorithm to recompute the MAC using the original message and 
appropriate key. If the two MACs are identical, then the 
message has not been altered. Users must remember that when 
using authentication by itself, the original message is 
transmitted in plain text. [Ref. 7:p. 5-6] 

The use of encryption and/or authentication, either 
alone or together, helps control unauthorized disclosure and 
modification of EDI data. In addition, controls may be 
required to restrict and/or prevent unauthorized physical 
access to EDI equipment. Both types of security must be 
addressed to ensure the optimal protection of an EDI system. 
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III. ELECTRONIC DATA INTERCHANGE DATA FORMAT STANDARDS 


A. INTRODUCTION 

As defined in Chapter II, electronic data interchange 
(EDI) is the inter-organizational, computer-to-computer 
exchange of business documentation and information in a 
standardized, machine-processable format. Fundamental to this 
definition is the reliance on, and use of, standardized, 
machine-processable data formats. The use of standard data 
formats, also referred to as "standards", is critical to the 
successful implementation and utilization of EDI, providing 
the key to making EDI practical. EDI standards facilitate the 
electronic exchange of data by providing a uniform method for 
configuring unstructured data into a structured format. This 
structuring and standardization of data format, allows 
computers to transfer, read, understand, and process 
information automatically, without additional human 
intervention. 

When discussing EDI data format standards it is important 
to remember that: 

• Compliance with the standards is strictly voluntary, 
decided among trading partners. 

• The standards specify only the format, rules, and data 
content of electronic business transactions, they do not 
address how trading partners will establish the required 
physical communications link to exchange EDI data. 
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B. TYPES OF DATA FORMAT STANDARDS 

Standards were developed to ease communication between 
organizations, with several different standards emerging. 
These different standards can be classified as being: [Ref. 
9:p. 22] 

• Proprietary. Proprietary data standards are those 
established by individual organizations for communicating 
with trading partners within a "closed" system. For 
example, Roadway Express, Inc. has its "E-Z 3ILL" shipment 
information management system which provides bill of 
lading, shipment status, and claims information to system 
users [Ref. 10]. 

• Industry-Specific. While proprietary data standards are 
established by individual organizations, industry-specif ic 
standards are set by an industry trade group, to promote 
intra-industry electronic communication. Examples of 
industry-specific standards include: l) Transportation 
Data Coordinating Committee (TDCC) - Transportation 
industry, 2) Uniform Communication Standard (UCS) 
Grocery industry, and 3) Warehouse Information Network 
Standards (WINS) - Warehouse industry. 

• Cross-Industry. In the United States there is only one 

inter-industry EDI data format: the American National 

Standards Institute (ANSI) Accredited Standard Committee 
X12 (ASC X12) Standard. 

• International. While ASC X12 is the standard for EDI in 
the United States, the standard for use in Europe and in 
many other parts of the world is the United Nations/EDI 
for Administration, Commerce, and Transport (EDIFACT). 
Worldwide, EDIFACT use is increasing and there is 
consideration for the future development of a universal 
standard resulting from an alignment between EDIFACT and 
ASC X12. 


Due to their widespread use and applicability to EDI 
information exchanges in the United States, the discussion of 
the structure of standards will specifically address the ANSI 
ASC X12 standard. 
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C. ANSI ASC X12 Standard 

The purpose of the ASC X12 standard is to provide format 
specifications for structuring business information d.e. ( 
that information found in "conventional" business documents) 
which is to be exchanged chrough EDI. The ASC X12 standard 
addresses such issues as: [Ref. 2:p. 54] 

• What documents can be transmitted electronically? 

• What information must be/can be included in each document? 

• What is the required sequence of the information? 

• What form of information is acceptable (e.g., numeric, ID 
codes, etc.)? 

• What is the meaning of specific pieces of information 
(data elements)? 

What is commonly referred to as the ASC X12 standard is 
actually a collection of related standards which together 
provide the desired data format and structure. Of the 
individual standards which comprise the ASC X12 standard, two 
categories of standards are of primary significance: 

• Transaction Set Standards 

• Foundation Standards 

1. Transaction Set Standards 

For the actual conveyance of information, the 
transaction set standard is of primary concern. In EDI 
terminology a transaction set refers to a specific group of 
data segments which represent a business document. The 
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information contained in an ASC X12 transaction set is 
primarily the same as that found on a conventionally printed 
document. Additionally, in a manner similar to that used with 
most paper forms, each transaction set is assigned a numeric 
code, for example, transaction set 858, Shipment Information, 
is the ASC X12 transaction set used for the electronic 
exchange of Freight Government bill of lading shipment 
information. 

Transaction set standards provide the guidelines 
required for structuring the data which is usually conveyed by 
conventional printed documents, so that it can be 
electronically exchanged among trading partners. Each 
transaction set standard addresses three basic components: 
[Ref. 6:pp. 9-11] 

• Transaction Set Tables 

• Data Segments 

• Data Elements 

As will be discussed, the above order (transaction set 
- data segment - data element) represents the hierarchical 
structure found within this EDI standard. For a transaction 
set: data elements are the smallest unit of data, groups of 
data elements form data segments, and specified arrangements 
of data segments (as delineated by transaction set tables) 
combine to form the actual transaction sets. 
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To illustrate the EDI concepts relating to transaction 
set tables, data segments, and data elements, the following 
discussion will use the Government bill of lading data 
depicted in Figure 5 4 . 

a. Transaction Set Tables 

Transaction set tables are the section of the 
standard which defines the overall format and content of the 
data contained in a particular transaction set. Each 
transaction set is composed of one or more tables, with many 
consisting of a hierarchical arrangement of three tables, 
which generally relate to the format of the printed document: 
[Ref. 6:p. 9] 

• Table 1 is the header area, containing information common 
to the entire transaction such as the date, name and 
address, and transaction number. 

• Table 2 is the detail area, which conveys the actual 
business transaction. This area contains information 
pertaining to descriptions, quantities, and prices. 

• Table 3 is the summary area. This portion of the 
transaction consists of information which again relates to 
the entire transaction such as total weights and charges, 
as well as transaction set control information. 


In defining the overall format and data content of 
transaction sets, transaction set tables specify which data 
segments must be used (mandatory), which data segments may be 


4 The Government bill of lading (GBL) , SF1103, is a Government 
document used for the procurement of freight and cargo 
transportation and related services from commercial carriers for 
the movement of material at Government expense. [Ref. ll:p. 257] 
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U.S. GOVERNMENT BILL OF LADING 
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CSX TRANSPORTATION INC. CSXT 
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MARINE CORPS MAINTENANCE COMMAND 491200 

5880 GATECO BLVD. , BLOUNT ISLE , - 

JACKSONVILLE, FL 32218 447178 


• CONaUNa MUM MM » MMM « IMMMMA 10 OM.OC <MM , 
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5880 GATECO BLVD., BLOUNT ISLE ICOI 
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CHARLESTON, SC 29408-7000 
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CHARLESTON, SC 29408-7000 


12. AFmOmtATlON CM AMU ABU 

SEB CONTINUATION SHEET #2 
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CSXT 
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RAIL ARMED GUARD ESCORT SERVICE REQUIRED 
SBE SHEET #3 FOR SPECIAL INSTRUCTIONS 
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COMMANDING GENBRAL, 470 
MARINE CORPS LOGISTIC BASE 
ALBANY, GA 31704-5000 
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CLASS "A*, "B", -C" EXPLOSIVES AND 
INERT MATERIAL AS DESCRIBED ON 
ATTACHED PAGES. 

■THIS GBL CONSISTS OF X2&. PAGES." 

"SEE ATTACHED PAGES FOR 

PLACARDING* 

2 . 868,163 
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TRAFFIC MANAGEMENT OPPICE (v«.im»omi 

NAVAL WEAPONS STATION, INNESS, SC / / 

CHARLESTON, SC 29408-7000_ 



jjc. ihum oppcsh 

JOHN SMITH, TMO 


*JM. COtfnUCTMMCMMf 09tm MO. OM OD 1 


Mf. POO rom NMO M CONDUCT 
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Figure 5 Sample Government bill of lading (GBL) 
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used (optional), as well as the required order in which the 
data segments must be arranged. Figure 6 depicts the type of 
information typically found in transaction set tables. [Ref. 
2:pp. 55 - 56] 


858 SHIPMENT INFORMATION 

This standard provides the format and establishes the data 
contents of a shipment information transaction set....This standard 
does not cover the semantic meaning of the information encoded 
in the transaction set. 

Table 1 - Header Area 


Segment Requirements Max 

]Q_ NalTle _ Designator Use 


ST 

Transaction Set Header 

M 

1 

BX 

General Shipment Information 

M 

1 

N1 

Name 

O 

1 

N3 

Address Information 

O 

2 

N4 

Geographic Location 

O 

1 


Table 2 - Detail Area 


Segment 

Requirements 

Max 


Name 

Designator 


(data axdudad for lustration purposes) 




Table 3 - Summary Area 


Segment 

Requirements 

Max 


Name 

Designator 



(data axdudad tar lustration purposes) 


Notes and Comments _ 

Requirements Designator M - Mandatory data segment O - Optional 
Max Use: Maximum use of data segment within a loop 
Segment ID: Identifies data segments contained in the transaction set 

Figure 6 Transaction set table (excerpt): ASC X12 

Transaction Set 858, Shipment Information 
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b. Data Segments 

The transaction set tables establish which data 
segments constitute a particular transaction set. A data 
segment is the intermediate unit of information in a 
transaction set consisting of functionally related data 
elements in a specified, predetermined, sequence. The data 
segment relates to a line of information found on a printed 
document, such as general shipment information (data segment 
BX) or an address (consisting of data segments Nl, N3, and 
N4) . 

Figure 7 depicts an example of the type of 
information contained in the ASC X12 Data Segment Directory. 
The BX data segment, general shipment information, is 
illustrated [Ref. 12:pp. 10.7.12-10.7.14]. As shown, the data 
segment directory defines the required format, structure, and 
sequence of data segments, and specifies for each data 
segment: [Ref. 2:pp. 56-58] 

• Data Segment Identifier. This is an alphanumeric label 
which identifies each particular data segment. In the 
preceding example, BX indicates the general shipment 
information data element. 

• Title. This states the plain language name or title of 
the specific data segment. 

• Purpose. This defines what the data segment is used for. 

• Data Elements. This specifies which data elements are 
used in a particular data segment, and indicates whether 
their use is mandatory, optional, or conditional. 

• Data Element Delimiter. This is a character, most 

commonly the (asterisk), which precedes each data 

element. The delimiter indicates where one data element 
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Figure 7 Data segment BX: General Shipment Information 


Segment 

identifier 


Segment 
title 

BX General Shipment Information 


Segment 

purpose 


To transmit identification numbers and other basic shipment data 



Notes and Comments 


BX05 contains the standard carrier alpha code of the 
original carrier receiving the shipment 













ends and another has begun, and acts as a position marker 
if an optional element is omitted. 

• Data Segment Terminator. This is a character used co 
indicate the end of the data segment. For illustration 
purposes, "N/L" will be used as the data segment 
terminator. 

• Notes and Comments. Plain text comments and 

amplification, as required. 


c. Data Elements 

The data element is the smallest unit of 
information in the ASC X12 standard and is defined in the Data 
Element Dictionary. As shown in Figure 8, the data element 
dictionary specifies for each data element the following 
information: [Ref. 6:p. 11] and [Ref. 2:pp. 58-60] 

• Data Element Identifier. A reference number to the data 
element dictionary. 

• Data Element Title. The plain text name of the data 
element. 

• Data Flement Definition. States the purpose of the 
transaction set. 

• Data Element Requirement Designator. Indicates whether 
the use of the data element is: 

M: Mandatory 

0: Optional, used at the discretion of the sender. 
If an optional data element is not used, the data 
element separator (e.g., "*") must be entered to 
mark the position. 

C: Conditional, data element use is dependent on the 
use of another element. The specific 

conditionality requirement is usually included as 
a note in the Data Segment Directory. 
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• Data Element Type. Specifies the form of the data: 

N - numeric 
R - decimal 

ID - identification code 
AN - alphanumeric string 
DT - date in YYMMDD form 
TM - time in HHMM form (24-hour clock) 

• Data Element Length. Indicates the maximum and minimum 
number of characters allowed. 


Data Sonant DataSamant 

Idantfflar TWe 

x 353 Transaction Set Purpose Code 

Code identifying the purpose of the transaction set. 


DataSamant 

DaSnWon 


DataSamant 
Typa 


Minimum 


DataSamant 

/ Lang* 


Data Element Attrib ut es 

Requirement MIN - 2 

Designator- M 

MAX - 2 

T VP»- |D V Maximum 


\ 


Data Elament 


DataSamant 

CodaVakia 



Code 

00 

01 

04 

14 

20 


Definition L9 °* h 

Original 

Cancellation 

Change 

Advance Notification 
Final 


Notes 

(None included in this example) 


Figure 8 Sample data element dictionary entry (corresponds to 
data segment BX01 from Figure 7) 


Figure 9 illustrates the representation of data 
elements, as defined in the data element dictionary, through 
the use of a data element box. The data element box conveys 
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essentially the same information as the data element 
dictionary with the addition of the data element reference 
identifier. The data element reference designator is a two- 
digit sequence number preceded by the data segment identifier, 
it identifies the position in which the particular data 
element appears in the data segment. In Figure 9 BX01 
identifies that this particular data element appears first in 
the sequence of data elements which comprise the BX data 
segment. This configuration is the one depicted in Figure 7, 



Figure 9 Data element as a data element box 
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To further illustrate the application of the ASC 
X12 standard, Figure 10 depicts selected information taken 
from the Government bill of lading shown in Figure 5, along 


with the corresponding ASC X12 translation. 


Sample GBL Content 
(selected) 

ASC XI2 Format 

(selected) 

Transaction Sot Purpose: original 
Transportation Method/Typo: rail 

Method of Payment collect 

Identification Number C-1,421,643 

Standard Carrier Alpha Code (SCAC): CSXT 
Shipment Qualifier individual shipment 
Capacity Lode: full capacity 

BX*00*R*CC*C1421643*CSXT**B~FN/L 

Origin 

Traffic Management Office 

Naval Weapons Station 

Charleston, SC 29408-7000 

! 

N1*SF*Traffic Management Office N/L 
N3*Naval Weapons Station N/L 
N4*Char1e8ton*SC*294087000**447178 N/L 

Destination 

Marine Corps Maintenance Command 

5660 Gateco BLVD, Blount Isle 

Jacksonville, FL 32218 

N1*ST* Marine Corp Maint Cmd N/L 

N3*5880 Gateco Btvd, Blount Isle N/L 
N4*JacksonvHle # FL32218~SL491200 N/L 


Figure 10 Selected GBL information translated to ASC X12 
format 


2. ASC X12 Foundation Standards 

ASC X12 has established "foundation standards" which 
are fundamental to all other ASC X12 standards. These 
standards define the ASC X12 EDI syntax, data segments, and 
data elements, as well as the control structure required for 
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information exchange. The foundation standards are essential 
for interpreting, understanding, and using the ASC X12 series 
of transaction set standards. The ASC X12 foundation 
standards consist of: [Ref. 6:p. 8] 

• X12.22 Segment Directory 

• X12.3 Data Element Dictionary 

• X12.5 Interchange Control Structures 

• X12.6 Application Control Structures 

a. X12.22 Data Segment Directory and X12.3 Data 

Element Dictionary 

The data segment directory and data element 
dictionary are used to define the particular segments and 
elements used in constructing EDI transaction sets. These 
were addressed previously under the discussion of transaction 
sets. 

b. X12.5 Interchange Control Structures 

The X12.5 Interchange Control Structures standard 
are best thought of as the EDI equivalent of "envelopes." 
These electronic envelopes consist of specialized data 
segments which uniquely identify individual transaction sets 
and functional groups {groups of transaction sets) within an 
EDI transmission, as well as providing the means to 
distinguish between individual EDI exchanges. 

As shown in Figure 11, the X12.5 standard provides 
three layers of EDI interchange envelopes: [Ref. 6:pp. 8-9] 
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ISA /interchange Control Header 


GS / Functional Group Header 


ST / Transaction Set Header 


Data Segments 
(i.e., shipment 
information) 


SE \ Transaction Set Trailer 


ST / Transaction Set Header 


Data Segments 
(i.e., shipment 
information) 


S E \ Transaction Set Trailer 


GE \ Functional Group Trailer 


IEA \ Interchange Control Trailer 


Figure 11 ASC X12.5 Interchange Control Structures standard 
Electronic "enveloping" 
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• Interchange Control Envelope 

• Functional Group Envelope 

• Transaction Set Envelope 

il) Transaction Set Envelope. The transaction set 
envelope is the innermost level of enveloping and corresponds 
to the data forming an individual transaction set. This 
envelope is bound by transaction set header (ST) ctnd 
transaction set trailer (SE) data segments. An ST data 
segment indicates the start of a new transaction set, 
specifies which transaction set is being used, and assigns a 
transaction set control number. For example, 

"ST*858*123456789 N/L", indicates the start of transaction set 
# 858 s , which is the Shipment Information transaction set and 
assigns a transaction set control number of "123456789". The 
SE data segment is used to indicate the end of each individual 
transaction set. In addition to signifying the end of the 
transaction set, this segment provides a count of all data 
segments included in the transaction set and repeats the 
assigned control number. [Ref. 12: pp. 10.7.5-10.7.128] 

(2) Functional Group Envelope. The functional 
group envelope is the middle level of enveloping which 
surrounds groups of similar transaction sets within an 
individual EDI transmission. The functional group envelope is 

5 Transaction set 858, Shipment Information, is defined by ASC 
X12 standard X12.18. 
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defined by functional group header (GS) and functional group 
trailer (GE) data segments. The functional group envelope 
provides specific information concerning the "enclosed" 
transaction sets, such as: 1) identifying the type of 
transaction sets contained in the group (e.g., shipment 
information, carrier shipment status inquiry, shipment status 
message, administrative message, functional acknowledgement, 
etc.), 2) a count of the transaction sets, 3) a date/time 
stamp of when the group was generated, 4) an assigned group 
control number, and 5) the version, release, and subrelease of 
the EDI standard being used within that group. [Ref. 12:pp. 
10.2.13-10.2.16] 

(3) Interchange Control Envelope. The outermost 
level of enveloping is the interchange control envelope, which 
is used to identify the transmission of one or more functional 
groups. This envelope is defined by the interchange control 
header (ISA) and interchange control trailer (IEA) data 
segments. As the outermost layer, the interchange envelope 
contains the addresses of both the sender and receiver of the 
enclosed "documents," identifies the characters which are to 
be used for the data element separators and segment 
terminators, and specifies the format and version of the 
interchange control segments and the functional group control 
segments. Other information provided includes an interchange 
control number, a count of the functional groups within the 
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interchange, and a date/time stamp. [Ref. I2:pp. 10.2.9- 
10.2.17] 

c. X12.6 Application Control Structures 

The X12.6 Application Control Structure is the 
document which contains the formal description of the EDI 
architecture and establishes the syntax which governs all 
other ASC X12 EDI standards. This standard contains the 
rules, structures, and formal definitions of all terms 
relating to electronic data interchange. [Ref. 6:p. 8] 

D. IMPLEMENTATION CONVENTIONS 

As discussed, EDI standards provide the format and 
structure for the electronic transmission of the essential 
elements of business documents. Contributing to the extensive 
reliance on the ASC X12 standard, as opposed to proprietary 
standards, is the inherent flexibility. This flexibility 
provides both advantages and disadvantages for the EDI user: 

• Advantage: Facilitates widespread application by allowing 
users to tailor the standards to meet unique requirements, 
thus satisfying numerous user needs. 

• Disadvantage: The potential exists for numerous 

interpretations concerning the actual implementation of 
the standards which could result in significantly 
increasing the complexity of exchanges between trading 
partners. 


The disadvantage created by the inherent flexibility of 
the X12 standard reflects the situation which exists with many 
paper documents. As there are many ways to fill out a blank 
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form, there are also numerous ways to populate an EDI 
transaction set. In response, implementation conventions 
(also referred to as implementation guidelines) exist which 
define the specific rules and requirements for using a 
transaction set to convey data. The conventions standardize 
the common practices and/or interpretations concerning the 
implementation of the ASC X12 standard by specifying the 
location and values of information found within a transaction 
set. By providing a common set of implementation rules, the 
conventions facilitate the successful exchange and 
interpretation of information among trading partners who 
conform to the implementation conventions. 

EDI standards and implementation conventions are the keys 
to unleashing EDI's potential for improving the effectiveness 
of electronic interorganizational communication. Without 
these, EDI is nothing more than a communications method which 
may or may not result in the efficient exchange of information 
among trading partners. It is important to remember that the 
use of, and compliance with, both the ASC X12 standard and 
implementation conventions is strictly voluntary. Through the 
development, approval, implementation, and use of the ASC X12 
standard and the corresponding implementation conventions, EDI 
significantly facilitates the efficient electronic exchange 
and comprehension of data among trading partners. 
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IV. ELECTRONIC DATA INTERCHANGE ARCHITECTURE 


A. ELECTRONIC DATA INTERCHANGE FUNCTIONS 

As defined in Chapter II, electronic data interchange 
(EDI) involves the computer-to-computer exchange of 
information, in a standardized, machine-processable format, 
between organizations. To facilitate this exchange requires 
the coordination of four resources: computer hardware, 
computer software, communications connections, and data format 
standards. The integration of these resources allows an EDI 
system to perform the following four primary functions 
required to create and exchange EDI messages: [Ref. 2:p. 80] 

• Mapping: Data mapping is the process of identifying the 

relationship between the EDI standard and an 

organization's internal application system (i.e., between 
each particular transaction set and an organization's 
information database). In identifying the relationship, 
mapping establishes the "link" between the format and 
structure requirements of the EDI standard and the data 
contained in an organization's computer system. Data 
mapping is a step in an organization's EDI implementation 
effort, and must be accomplished before EDI messages can 
be exchanged. Once the link is established there is no 
further requirement to re-map data. The only situation 
which would result in re-mapping would be a change to the 
structure of an organization's application system or a 
change to the particular EDI standard. 

• Extraction (or conversion): Extraction is the first step 
in formatting the data to be exchanged through EDI. In 
this process, data residing in locations which have been 
previously mapped, is placed in files (commonly referred 
to as "flat files") prior to the actual structuring to the 
required format of the EDI standard. 
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• Translation: Translation is the step where the data is 
actually structured to and from the EDI standard data 
format. 

• Communications: Communications is the process of 

conveying data from one trading partner to another. 


Together these four functions, along with the system 
hardware, comprise the EDI system architecture. Figure 12 
shows the relationship between these functions in an EDI 
environment. It is important to note that these functions are 
generic and not dependent on specific hardware, software, 
communications protocol, or operating environment. [Ref. 2:p. 
80] 



INCOMING EDI 
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B. SYSTEM DESIGN 


Of the four resources required for an EDI system, two of 
these, the computer hardware and the communications 
connections compose the System Design. System design refers 
to the actual equipment (hardware) as well as the physical 
communication connections required for the exchange of 
information electronically in a particular application. 

1. Hardware Requirements 

Remembering that EDI is a technology implies that 
there is no EDI specific hardware configuration. Although 
there are numerous hardware systems which are fully capable of 
supporting EDI applications, Figure 13 illustrates the four 
basic system hardware options for EDI implementation: [Ref. 
2:p. 87] 

• Mainframe Only. With this option all the EDI software 
resides on the organization's mainframe computer system. 
Here the mainframe is used for both internal data 
processing as well as EDI related functions. 

• Microcomputer (PC-based) . A second option is to have the 
EDI software reside on a microcomputer (PC) which performs 
all EDI functions. This arrangement is referred to as 
"stand-alone" EDI, since the EDI activities are separate 
from all other computer activity within the organization. 
When using this approach outgoing data must be manually 
entered into the PC before it can be exchanged 
electronically and incoming data must be manually entered 
into the organization's primary computer system. 

• PC as a Front-end Processor. A third option is to use a 
microcomputer linked to the mainframe. With this 
arrangement, the PC contains all required EDI software and 
performs all EDI functions. Outgoing data is transferred 
from the mainframe to the PC (downloading) with incoming 
data being transferred from the PC to the mainframe 
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(uploading). As opposed to the stand-alone option, the 
uploading and downloading is accomplished electronically. 

• Dedicated EDI Operating System. This final option is 
basically an extension of che previous method (PC as a 
front-end processor). The main difference is in the 
increased capacity to handle a larger volume of 
transactions. 



Figure 13 EDI system hardware options 


Each application of EDI technology is unique, being 
situationally dependent on numerous variables such as: 
organizational commitment to EDI, current and anticipated 
volume of data to be exchanged via EDI, and budgetary 
constraints. The specific hardware configuration employed 
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should be selected based on an evaluation of organizational 
requirements along with the consideration of the advantages 
and disadvantages of each of the four basic configuration 
options, as depicted in Figure 14. [Ref. 2:pp. 87-89] 

2. Communications 

Electronic data interchange facilitates, and depends 
on, communication between trading partners. For EDI exchanges 
to occur between trading partners, the organizations must, in 
some way, be linked together. 

A common misconception is that the adoption of the 
ANSI ASC X12 standard will eliminate communication barriers 
between incompatible computer equipment [Ref. 3:p. 75], The 
ANSI ASC X12 standard specifies only the format and data 
content of electronic business transactions, thus eliminating 
the problem of trading partner computers understanding each 
other. The standards do not define how the required computer- 
to-computer communications link shall be established or how 
the exchange of data is to occur. Issues concerning 
differences in transmission modes, protocols, and transmission 
speeds still need to be addressed by the users of these 
standards. In establishing this vital communications link, 
there are primarily two alternatives for trading partners to 
consider: 

• Direct 

• Value Added Networks (VANs) 
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Figure 14 Hardware option advantages and disadvantages 
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a. Direct 


As illustrated in Figure 15, in direct, or point- 
to-point, EDI, trading partners exchange electronic 
transmissions directly from the computer of the sender to the 
computer of the receiver. This linkage is usually achieved 
through the use of telephone lines coupled with a computer 
modem. 



Figure 15 Direct EDI communication linkage between trading 
partners 


For this type of access to work, the trading 
partners must be compatible from a communications standpoint; 
this means that they must use the same communication protocols 
in terms of line speeds and baud rates. The parties must also 
either use the same standard (e.g., ASC X12) or have the 
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capability of translating from one standard to another. 
Additionally, agreements between parties must be reached with 
regards to the hours of availability of each comr'iter system. 
With direct linkage, the receiving computer must be free to 
receive when the sending party transmits a message. [Ref. 

2:pp. 101-102] 

The direct system is best suited when an 
organization is communicating electronically with only a few 
trading partners. As the number of trading partners 
increases, so does the complexity of establishing and 
maintaining direct communication links. This increased 
complexity arises from factors such as: [Ref. 9:p. 29] 

• Differences in communication protocols. 

• The requirement for prearranged transaction transmission 
times. 

• Transactions sent to separate trading partners must each 
be individually sent, complicating the connect/disconnect 
effort. 

• Communicating among different time zones. 

• Variations in the standards used by the trading partners. 

Jb. Value Added Networks 

Some of the concerns encountered with the use of 
direct linkage, such as differences in communication 
protocols, times zones, and variations among standards, 
required to support multiple trading partners, can be 
alleviated through the use of a value added network (VAN). As 
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shown in Figure 16, a value added network accs as a "go- 
between" for organizations wishing to communicate with 
multiple trading partners. 



The basic function of any value added network is to 
receive, sort, store, and forward electronic messages. In 
essence, VANs provide the EDI communications skills, 
expertise, and equipment necessary to communicate 
electronically with multiple trading partners. Some of the 
services which value added networks provide include: [Ref. 
9:p. 30] 

• Elimination of communications compatibility problems. 

• The ability to reach multiple trading partners with "one 
call". 

• Electronic mailbox services. 
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• The existence of a buffer between your computer and that 
of your trading partners (instead of direct access between 
computer systems). 

• Standards/format translation. 

• Activity reporting and audit information such as 
maintaining an activity log showing what was received from 
a particular organization and where it was sent, as well 
as recording what was placed in an organization's mailbox. 

Of the services mentioned above, the most 
fundamental is the electronic mailbox. In providing this 
service, the VAN will establish a separate electronic mailbox 
for each trading partner. As shown in Figure 17, the VAN 
receives messages (mail) from senders, sorts the messages by 
intended receiver, and delivers the messages to the receiver's 
mailbox. One of the primary advantages of the electronic 
mailbox provided by most VANs is that they allow 24-hour a 
day, 7-day a week access between trading partners, eliminating 
the requirement to prearrange transaction times. [Ref. 2:p. 
103] 

Many communication options exist and there is no "one 
best method." As with hardware, each organization must 
evaluate the options available (e.g., direct communications or 
the use of a value added network) , with respect to their 
particular capabilities and communication requirements, as 
well as those of their trading partners. 
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Figure 17 Value Added Network as an Electronic Mailbox 


C. SOFTWARE REQUIREMENTS 

EDI software provides the set of computer instructions 
which control the data handling operations of the EDI system. 
The software is central to the operations which translate data 
from unstructured, organization-specific, formats into the 
structured EDI data format (e.g., ANSI ASC X12 standard). In 
addition to the standard related aspects of an EDI system, 
software is also used to control required communication 
interfaces such as establishing the speed and type of 
transmission and performing error detection during the data 
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transfer. EDI system software also performs these activities 
in reverse, receiving the message and then translating it from 
the EDI standard into the organization-specific data format. 

1. Primary Software Functional Areas 

Figure 18 illustrates the role of EDI software in 
performing the primary functions which comprise a typical EDI 
system architecture, as depicted in Figure 12. Of these, 
three are performed exclusively by EDI sctcware: 1) Mapping, 
2) Data extraction (conversion), and 3) Translation, with the 
final function, communications, accomplished through a 
combination of hardware and software. [Ref. 2:pp. 80-82] 
a. Data Mapping 

The exchange of information through EDI requires 
the conversion of organization-specific "raw data" into a 
standardized, machine-processable format. Data mapping is a 
preliminary step in this conversion process which focuses on 
information location identification. As a prerequisite of the 
data extraction (conversion), translation, and communication 
software functional areas, mapping primarily occurs as part of 
an organization's EDI implementation efforts. Mapping 
involves an examination of the standard (e.g., ASC X12; to 
identify the data required to create an EDI message and then 
identifying where in the organization that information resides 
(i.e., where in the organization's database). In identifying 
this relationship, mapping establishes the "link” between the 
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Figure 18 Primary EDI software functions 


format and structure requirements of the EDI standard and the 
data contained in an organization's computer system. Once the 
link is established there is no further requirement to re-map 
data. The only occasion which would result in re-mapping 
would be a change to the structure of an organization's 
application system or a change to the particular EDI standard. 
[Ref. 2:p. 80] 

b. Data Extraction (conversion) 

Extraction, more appropriately referred to as 
"conversion," is the process of collecting the previously 
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identified, mapped, information and converting it into a 
usable format. Usually, the data are extracted from the 


organization's database and restructured into a "flat file." 
This flat file typically consists of fixed-position records 
and is used to "hold" the data awaiting translation. [Ref. 2: 

p. 80] 

c. Translation 

The principal purpose of translation software is to 
format the data contained in flat files to and from standard 
transaction set formats (e.g., the 858 transaction set). 
Translation performs this function for both outbound 
(generation) and inbound (interpretation) messages. 

For outbound messages, generation involves 
arranging the data in the exact structure necessary to meet 
the requirements of the standard. To perform the translation, 
the generation software usually uses a table structure, 
consisting of the data element dictionary and syntax rules for 
data segments and elements of the appropriate EDI transaction 
set. When a transaction set is to be generated, the software 
selects the appropriate table and performs the translation 
automatically, with the output being a syntactically correct 
EDI transaction set. [Ref. 2:p. 80] 

For incoming messages the process is reversed. The 
interpretation software performs similar functions, taking a 
syntactically correct EDI transaction set and converting it to 
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a format that the organization's application database can 
understand. 

d. Communications 

In order to exchange EDI messages, EDI systems must 
be capable of passing information to and receiving information 
from established communications links. These activities are 
controlled by communications software. Some of the typical 
functions provided by communications software include: 

• Automatic dialing 

• Managing and maintaining trading partner phone numbers 

• Establishing the type and speed of the data transfer 

• Data transmission error detection 

• Maintaining an activity log of transactions 

2. Additional Software Functions 

In addition to the primary functional areas discussed 
above, an organization may also utilize the following types of 
software in their EDI system: 

e Bridging software 

• Security software 

a. Bridging Software 

As shown in Figure 19, bridging software links 
various application programs within an organization. This 
linkage allows incoming EDI messages to be used to generate 
outbound EDI messages, such as an order receipt 
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acknowledgement or an automatic response to a statue inquiry. 
As EDI eliminates the need to manually reenter data between 
organizations, bridging software eliminates the need to 
manually reenter data between various departments within an 
organization. Through the use of bridging software, once data 
enters an organization's computer system the information is 
available to "flow" between internal applications as required; 
this is indicated by the double-headed arrows in Figure 19. 
[Ref. 2:pp. 83-84] 
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Figure 19 Bridging software application 

b. Security Software 

Chapter II highlighted the importance of, and 
growing concern over, the security of EDI systems. The two 
types of cryptographic security discussed, encryption and 
authentication, are software approaches addressing this 
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concern, and they can be integrated into an EDI system as the 
situation warrants. 


The foregoing discussion presented the range of 
potential EDI software functions. The actual software 
functions performed in an individual organization's EDI system 
will primarily depend on whether an application-to-application 
or a door-to-door approach is taken. 

With an application-to-application approach to EDI, 
information flows directly from the sender's application 
database to the recipient's without human intervention. In 
this case, the EDI system software will provide all four of 
the primary functions of data mapping, conversion, 
translation, and communications. 

In contrast, with a door-to-door approach, manual 
input is used to generate an outgoing transaction set, and the 
incoming transaction set is manually read and interpreted. 
Here, the only functions performed by the EDI system software 
are those of translation and communication. The mapping and 
conversion functions are accomplished through manual input and 
interpretation. 

The application-to-application and door-to-door 
approaches represent the two extremes concerning the level of 
integration of EDI with the computer system of an 
organization. As more organizations implement EDI technology, 
it is increasingly likely that there will be situations where 
a mixed approach is encountered. In this context, a mixed 
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approach would simply be a situation where one trading partner 
might have EDI fully integrated with its computer system while 
its trading partner may be utilizing a microcomputer based 
approach to EDI transactions. An example of this would be 
Roadway Express, Inc., where Roadway has taken an integrated 
approach on the application-to-application end of the spectrum 
yet many of its smaller trading partners are utilizing a door- 
to-door level of EDI integration. 

As discussed, the choice as to the appropriate EDI System, 
composed of hardware, communications, and software, will be 
situationally dependent. The specific configuration selected 
will be determined by the specific needs and resources of the 
parties involved. As transaction volume and available 
resources allow, maximum benefits will be attained with a 
greater implementation of EDI in the transaction process 
(e.g., an application-to-application approach, where data is 
exchanged electronically with minimum human intervention). 
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V. DEPARTMENT OF DEFENSE IMPLEMENTATION OF ELECTRONIC DATA 
INTERCHANGE 

A. ELECTRONIC COMMERCE 

Like many organizations, the Department of Defense relies 
on a multitude of manual and automated systems to carry out 
its business functions, such as acquisition, logistics, and 
transportation. Though effective, these systems are not 
necessarily the most efficient means of accomplishing the 
required tasks. With the existing environment of diminishing 
resources, efficiency in operations continues to take on 
increased significance. As organizations respond to pressures 
to "do more with less,” advances in information technology 
emerge which offer increased capabilities and efficiencies in 
conducting these business functions. 

The Department of Defense, in an effort to take advantage 
of emerging electronic information technology capabilities, 
has adopted the approach of Electronic Commerce, the digital 
exchange of all information needed to conduct business. DoD's 
concept of Electronic Commerce (EC) involves the integration 
of electronic data interchange, electronic mail, electronic 
bulletin boards, electronic funds transfer, and related 
technologies into a comprehensive electronic-based system 
which encompasses all DoD business functions. The EC concept 
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is focussed on exchanging business information faster, making 
information more accessible, and sending information directly 
to those who need it. The objective of DoD's EC program is 
not to just automate existing manual processes, but to 
implement the necessary systems, capabilities and procedures 
which will allow DoD activities to fundamentally alter and 
improve the manner in which they accomplish their business 
operations. [Ref. 7:p. 1-2] 

Although EC encompasses a variety of electronic 
information processing technologies, the key to DoD changing 
its business practices, from a paper-based document processing 
to a total electronic environment is electronic data 
interchange. The DoD name for this initiative is "Electronic 
Commerce through EDI." [Ref. 13:p. 1-1] 

B. ELECTRONIC COMMERCE THROUGH EDI 
1. Policy Milestones 

The strategic goal of DoD's current EDI efforts is to 
provide the capability to initiate, conduct, and maintain its 
external and internal business related activities utilizing an 
electronic media [Ref. 14:p. 3]. In the process of 
implementing DoD's EDI initiatives, the following policy 
milestones have occurred: 

s Deputy Secretary of Defense (DEPSECDEF) memorandum commits 
DoD to industry EDI standards (May 1988). 

• Treasury endorses DoD plan to use electronic funds 
transfer (EFT) (March 1989). 
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• Title 41, Code of Federal Regulations changed to permit 
using EDI for documenting and paying transportation bills 
(April 1989) . 

• Defense Logistic Agency (DLA) appointed as Executive Agent 
(EA) for EDI (May 1990). 

• Defense Management Report Decision (DMRD) 941 commits DoD 
to replace identified documents, key EDI candidates, with 
the appropriate EDI equivalent transaction set (November 
1990) . 

• Federal Information Processing Standards Publication (FIPS 
PUB) 161 established the rules and formats for conveying 
information electronically (March "’.991) . 

• DoD EDI Program Management responsibilities transferred 
from DLA, formerly the Executive Agent, to the Defense 
Information Systems Agency (DISA) (April 1993). 


In examining these milestones, two policy documents 
stand out as significant to establishing the foundation for 
DoD's EDI efforts: 

• Deputy Secretary of Defense memorandum of 24 May 1988 - 

Electronic Data Interchange of Business-Related 

Transactions. 

• Defense Management Report Decision 941 - Implementation of 
Electronic Data Interchange in DoD. 


a. DEPSECDEF Memo 

In May of 1988, the Deputy Secretary of Defense 
issued a memorandum specifying that EDI was to "become the way 
of doing business" for the Department of Defense. Recognizing 
the potential benefits of EDI, Deputy Secretary Taft directed 
that: [Ref. 15] 

Consistent with our commitments to improve productivity 
and move toward a paperless environment, all DoD 
components should make maximum use of electronic data 
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interchange (EDI) for the paperless processing of all 
business-related transactions. 

Additionally, this memorandum specified the 
standard which would be used by DoD in the conduct of business 
via EDI. Specifically: [Ref. 15] 

The American National Standards Institute X12 uniform 
standards for inter-industry electronic interchange of 
business transactions will be employed as the standard for 
EDI, providing a common approach to implementation and a 
single, coordinated DoD position to industry. 

b. DMRD 941 

In November 1990, Defense Management Report 
Decision (DMRD) 941 was approved by the Deputy Secretary of 
Defense. DMRD 941 directed the development, implementation, 
and management of a standard DoD EDI system. As part of the 
move to a "paperless" environment, DMRD 941 identified 16 
forms and documents as "key EDI candidates," initiating their 
replacement with their electronic equivalents. 

2. Organization 

The Assistant Secretary of Defense for Production and 
Logistics, ASD (P&L), was initially given responsibility for 
oversight of EDI development efforts within the Department of 
Defense. The ASD (P&L) in turn designated the Defense 
Logistics Agency (DLA) as the Executive Agent (EA) for 
managing the funding, development, and implementation of a 
standard DoD EDI system. [Ref. 14] 

The EA for EDI was established to encourage and 
coordinate the implementation of EDI within DoD. As Dor's 
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Executive Agent for EDI, DLA's responsibilities included: 
[Ref. 13:p. 3-1] 

• Developing DoD-wide strategies for implementing EC/EDI. 

• Providing and maintaining standard implementation 
guidelines for EDI. 

• Ensuring compliance with policies and standards. 

• Providing common-user support standards and services for 
use throughout DoD. 

• Promoting EDI implementation by focusing on broad DoD and 
industry implementation opportunities. 

• Promoting a "single face to industry" for DoD EDI efforts. 

In April of 1993, DoD EDI Program Management 
responsibilities were transferred from DLA to the Defense 
Information Systems Agency (DISA). In assuming these duties, 
the Defense Information Systems Agency is responsible for the 
execution of the Department of Defense EDI technical 
infrastructure and related operations. [Ref. 16:p. 2] 

3. Proposed Savings and Benefits 

As resources continue to diminish, it is increasingly 
necessary for DoD to develop, implement and utilize processes 
which maximize efficiency and maintain required levels of 
readiness while remaining within budgetary constraints. 
Through the implementation of EDI, DoD and its trading 
partners expect to derive many of the cost reduction and 
efficiency benefits discussed in Chapter II, specifically: 
[Ref. 14:p. 2] 
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• Reduction in paper handling costs. 

• The elimination of duplicate data entry. 

• Payment systems which work faster with fewer errors. 

• Better decision making due to more accurate and timely 
data. 

One of the first steps in DoD's implementation of EDI, 
and the realization of corresponding benefits, was the 
identification of those documents whose information would 
eventually be exchanged through EDI. In 1990 DoD had over 
2,100 documents which were potential candidates for EDI. Of 
this total, almost two-thirds of the documents (1,395) were 
standardized Defense Department (DD) forms; 155 were General 
Services Administration Standard Forms (SF); with the 
remaining documents (almost 600) being either service- 
specific, internal, or interagency forms. [Ref. I3:p. 2-1] 

In the process of identifying which documents to 
"start with", the first step was the identification of areas 
of opportunity within DoD. Using primarily private-sector 
experience in EDI as a guide, four key opportunity areas were 
identified: 1) procurement and contract administration, 2) 
transportation, 3) supply and maintenance, and 4) fuels. [Ref. 
13:p. 2-1] 

With these key opportunity areas identified, the next 
task was to determine, within these areas, which routine paper 
documents offered the greatest EDI potential. In selecting 
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these documents, emphasis was placed on the following 
criteria: [Ref. I3:p. 2-2] 

• The document should be used extensively throughout DoD. 

• Currently the document should be manually processed. 

• The document should have multiple users (this dramatically 
increases both the amount of paper flowing through the 
system and the labor required to process the paper). 

• The document should have a private-sector counterpart 
(would help to ease acceptance and replacement through 
EDI) . 

Using these criteria, 16 documents 6 were identified 
as having the greatest potential for return on investment, and 
were designated as the "key EDI candidates." 7 Table I 
identifies these documents and their associated annual volumes 
by opportunity areas. 3 [Ref. 14: Table 1] 

For the documents identified, the total anticipated 
benefits associated with EDI implementation can be classified 
as either: 

• Direct Cost Savings 

• Indirect Cost Savings 


6 Some of the documents identified (e.g., SF 18 and SF 30) are 
processed in different ways. Each variation is treated separately. 

7 Appendix B contains additional information on each of these 
documents. 

8 The numbers shown are 1990 estimated annual volumes. 
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TABLE I KEY EDI CANDIDATES 


Documents By Opportunity Area 

Estimated 

annual 

volume 

(millions) 

J Procurement and Contract Administration | 

DD Form 1 1 55 

Order for Supplies and Services 

1 1.00 

SF 18 

Request for Quotation (writtenl 

5.40 

SF 18 

Request for Quotation (Telephone) 

4.00 

SF 30 

Amendment of Solicitation/Contract Modification (Local) 

3 75 

SF 30 

Amendment of Solicitation/Contract Modification (Non-Local) 

0.25 

DD Form 250 

Material Inspection and Receiving Report 

2.50 

SF 129 

Solicitation Mailing List Application 

1.00 

SF 1 443 

Contractor Request for Progress Payments 

0 40 

| Transportation 

SF 1103 

SF 1 1 13 

Freight GBL. CBL, and Public Voucher 

2.3C 

SF1203 
619/619-1 

SF 1113 

Personal Property GBL, Statement of Accessorial Services Performed, and 

Public Voucher 

0.80 

SF1169 

SF 1113 

Government Travel Request and Public Voucher 

0.39 







MT 364R 

Standard Tender 

0.03 

| Supply and Maintenance j 

SF 364 

Report of Discrepancy 

0.30 

SAV 926 

Monthly Repor., Receipt of Repairables 

0.28 

SF 368 

Product Quality Deficiency Report 

0.10 

SF 361 

Transportation Discrepancy Report 

0.03 

| Fuels 

| DD Form 1898 

---.- 

Aviation Fuels Sales Slip 

0.30 


Note: GBL = Government Bill of Lading; CBL = Commerce! Bill of Lading; MT = MTMC; SAV = Standard Aviation 
Systems Command 
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a. Direct Cost Savings 

Within DoD, the manual process of document handling 
consists of several labor intensive and costly activities 
including: document distribution (making copies of documents 
and distributing them to users); mailing (primarily postage 
and the purchase of envelopes ); document receipt (sorting and 
routing); document processing (reconciling and auditing); 
document preparation (for data entry); data entry (which can 
involve multiple entries if the information is entered into 
more than one computer system); error resolution (checking for 
and correcting mistakes) ; document storage and retrieval; and 
telephone procurement. With the implementation of EDI, most 
of these manual procedures are eliminated with the resulting 
savings defined as direct cost savings. [Ref. 14:p. 4] 

In determining the direct cost savings associated 
with the elimination of these manual document processing 
activities, engineered work standards were used. These work 
standards, supplied by the U.S. Army Finance and Accounting 
Center, detail the labor content and time allotment for 
performing the manual activities described above. The direct 
cost savings associated with the elimination of these 
activities were obtained by multiplying the work standards by 
the appropriate Government Schedule (GS) labor rate. Table II 
is structured to show the predominant manual document handling 
operations along with activities commonly associated with 
their occurrence. Reflecting that all doc’iments are not 
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TABLE II EDI DIRECT COST SAVINGS': PER ACTIVITY, PER DOCUMENT 


Operation 

Activity 



mm 

Low 

Medium 

High 

Document 

distribution 

Separate 
documents, make 
copies, route 
to mail room, 
prepare address 
labels, stuff 
envelopes 

complexity of 
operations 

0.02 

0.04 

0.06 

Mailing 

Procure 
envelopes and 
stamps 

number of 
documents 
requiring single 
envelopes 

0.11 

0.16 

0.26 

Document 

receipt 

Receive, open, 
sort, date, 
stamp, route 

complexity of 
sorting 

0.01 

0.02 

0.03 

Document 

processing 

Match, 
reconcile, 
audit 

document 
complexity and 
data volume 

0.15 

0.26 

0.41 

Document 
preparation 
and control 

Examine and 
prepare for 
data entry 

document 

complexity 

0.13 

0.21 

0.47 

Data entry 

Enter data 

volume of data 

0.06 

0.17 

0.68 

Error 

resolution 

Research and 

correct errors, 

prepare 

corre spondence 

volume of data 

0.05 

0.07 

0.09 

Document 
storage and 
retrieval 

Log, separate, 
sort, 

microfilm, box, 
file, retrieve 
documents 

filing and 

microfilming 

requirements 

0.10 

0.16 

0.28 

Telephone 

Procurement 

Procure 
material and 
services 

number of 
telephone 
solicitations 

1.78 

3.50 

5.33 


Cost category figures are based on 1990 data. 


in the same fashion. Table II also shows the per- 
per-document direct cost savings segregated into 
low, medium, or high cost categories. [Ref. 14:p. 4, Table 2] 


processed 

activity, 
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In estimating the total direct cost savings, level 
of effort determinations were made for those DoD activities 
(e.g., procurement office, transportation office, receiving 
office, etc.) involved with the handling and processing of the 
associated documents. This level of effort information was in 
turn used to calculate the expected savings per-document 
information displayed in Table III, by identifying the 
appropriate costs to apply from the low, medium, or high cost 
categories shown in Table II. Additionally, all operating 
costs, except telecommunications, were assumed to remain 
constant. With telecommunication costs expected to increase 
in an EDI environment, these costs were subtracted from the 
direct cost savings. Using the savings per-document data 
along with the estimated annual volume information from Table 
I, the resulting annual net savings associated with each of 
the identified documents was computed. Table III provides the 
total savings information for each opportunity area as well as 
the overall, expected total. [Ref. 14: Table 3] 

As depicted in Table III, if all documents 
identified as key EDI candidates were replaced with 
appropriate EDI transaction sets, the estimated annual direct 
cost savings to DoD could be $9 8 million. Additionally, Table 
III shows that a majority of the potential savings ($84.5 
million or 86 percent) are associated with the procurement and 
contract administration functional area. The projected 
savings in transportation would contribute $11.8 million 
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TABLE III SUMMARY OF TOTAL DIRECT COST SAVINGS 


Oocumen? oy Opportunity Ar%t 

Estimated annual 

vO'uma mill,one. 

Savings par 
document i 

mm 

| Procurement end Comreci Administration |j 

DO Fo''"'’ 1156 

Oca' *o t S_oo'ee anc Sarvcea 

11 00 

3 36 

36 9 

SF 18 

Rec-ee* *or Quotation w»-tt«n. 

6 40 

0 84 

4 6 

SF 18 

Request for Quotation .Telephone 

4 00 

3 46 

13 B 

SF 30 

Amendment of Solicitation,Contract MooiFcaoon 'Loca< 

3 76 

3 36 

12 6 

SF 30 

Amendment of Solicitation Contract Modification t Non-Local l 

0 26 

3 98 

1 0 

DO For-n 260 

Matanai Inapection and Receiving Report 

2.60 

6.72 

14 3 

SF 129 

Solicitation Mailing Lift Application 

1 00 

0 94 

0 9 

SF 1 443 

Contractor Radueet tor Progreea Peymenta 

0 40 

1 27 

0 6 

Subtotal 

84 6 

Transportation jj 

SF 1103 

SF 1113 

F'miQnx GBL. CBL. ano Public Voucher 

2.30 

3 12 


SF 1203 
619/619-1 

SF 1113 

Pereonai Property GBLa. Statement of Accaeioriat Services 
Performed, and Public Voucher 

0.80 

4 46 

B 

SF 1169 

SF 1113 

Government Travel Request and Public Voucher 

0.39 

1.87 

0 7 

— 

Voucner Stub and Check, 

0.27 

0 87 

0 2 

MT364R 

Standard Tandar 

0 03 

2 28 

0.1 

| Subtotal 

118 

| Supply /Maintenance ]J 

SF 364 

Reoort of Discrepancy 

0 30 

2.06 

0 6 

SAV 926 

Monthly Report of Repauablee 

0.28 

1 80 

06 

SF 368 

Product Quality Deficiency Report 

0.10 

1.47 

0.1 

SF 361 

Transportation Dieerspancy Report 

0.03 

1.29 

0.1 

| Subtotal 

1 3 

1 Fuel. || 

DO Form 1898 

Aviation Fueit Slip 

0 30 

1 26 

0.4 

Subtotal 

04 

Total 

98 0 


(12 percent) annually, with supply/maintenance and fuels 
contributing an estimated $1.3 million and $0.4 million 
respectively. Based on the analysis presented in DMRD 941, 
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Dot) has the potential to realize total direct cost savings of 
$98 million annually, provided that all the key candidate 
documents are replaced by their electronic equivalents. 

Jb. Indirect Cost Savings 

While the direct cost savings resulting from the 
implementation of EDI are substantial, they are only part of 
the total cost savings equation. The indirect benefits 
associated with EDI are also significant and many private 
sector organizations have found that the indirect cost savings 
resulting from EDI outweigh the direct cost savings. Examples 
from the private sector include: inventory reductions, 
improved customer service, reduced manufacturing costs, 
streamlined operations, and increased asset visibility. In 
addition to these benefits it is expected that DoD will also 
experience improved quality control, enhanced contract 
management, better prepayment auditing, increased price 
discounts, and reduced interest payments. [Ref. 14:p. 5] 

In an analysis of the indirect cost savings 
expected from the electronic exchange of the key EDI candidate 
documents, the Logistics Management Institute (LMI) performed 
an economic analysis involving: l) inventory reduction, 2) 
streamlined and enhanced business operations, 3) reduced 
prepayment auditing, 4) avoidance of interest costs, 5) 
negotiated price reductions and discounts, and 6) reduced 
shipment tracing. In the six areas of indirect benefits 
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examined, it was estimated that with a fully implemented EDI 
system DoD could save between 5152 million and $301 million 
annually in indirect costs, between $1.55 and $3.07 for every 
dollar of direct savings. [Ref. 13:pp. 2-8 - 2-12] 

As a result of the LMI analysis, it was determined 
that an indirect to direct cost savings ratio of 1.8 to l was 
appropriate for calculating the indirect cost savings 
correlating to the documents discussed above. Applying this 
ratio to the projected $98 million direct cost savings, yields 
ar. indirect cost savings of $176 million as the projected 
annual indirect costs savings. [Ref. 14:p. 6] 

c. Total Direct and Indirect Coat Savings 

Adding these projected direct and indirect cost 
savings results in a potential $274 million annual total cost 
savings, if DoD were to utilize EDI in the electronic exchange 
of all documents identified in Table I. Though the 
calculations presented in the LMI report (A Business Case for 
Electronic Commerce) and DMRD 941 tended to be intentionally 
conservative, actual total cost savings will be influenced by 
several factors. Foremost among these factors are the 
indirect to direct cost savings ratio and the EDI 
implementation rate. 

Through the implementation of EDI, DoD has the 
potential to substantially reduce its cost of conducting 
business. Extrapolating on the experiences of the commercial 
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sector, it is anticipated that the greatest benefits of EDI 
implementation will not come from the direct cost savings but 
from the indirect benefits associated with the critical role 
EDI has in supporting and streamlining business procedures. 
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VI. DEFENSE TRANSPORTATION ELECTRONIC DATA INTERCHANGE 
IMPLEMENTATION 

A. DEFENSE TRANSPORTATION OVERVIEW 

The objective of defense transportation can be summarized 
as having the capability to satisfy military transportation 
requirements during times of peace and war, with emphasis on 
service, economy, and readiness. The major players in defense 
transportation, which is concerned with the movement of DoD 
forces, equipment and supplies, consist of: 

• United States Transportation Command (USTRANSCOM) 

• Air Mobility Command (AMC) 

• Military Traffic Management Command (MTWC) 

• Military Sealift Command (MSC) 

1. United States Transportation Command 

The United States Transportation Command (USTRANSCOM) 
is designated as the single manager of Department of Defense 
common-user transportation 9 . The broad USTRANSCOM mission is 
to provide global air, land, and sea transportation to meet 
national security needs. It supports the other unified and 


9 Common-user transportation assets consist of those assets 
either government-owned or -chartered that are under the 
operational control of AMC, MSC, or MTMC for the purpose of 
providing common-user (available and utilized by all services) 
transportation to DoD in peace or war. (Ref. 17:p. 1-8] 
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specified commands by managing and providing its components' 
common-user transportation forces in peace and war. 
Established in April 1987, USTRANSCOM is a unified command 
with three transportation component commands (TCCs): the Air 
Force's Air Mobility Command (AMC), the Army's Military 
Traffic Management Command (MTMC), and the Navy's Military 
Sealift Command (MSC). On 14 February 1992, the Secretary of 
Defense signed a directive giving USTRANSCOM control of its 
component commands in time of peace as well as war. The 
directive reassigned the common-user transportation assets of 
the Air Mobility Command, Military Traffic Management Command, 
and the Military Sealift Command from their respective 
services to USTRANSCOM. The individual services retain only 
service-unique or organic theater assigned assets. [Ref. 
18:pp. 18-19] 

2. Air Mobility Command 

The Air Mobility Command (AMC) is the U.S. military's 
primary provider of rapid, flexible, and responsive airlift. 
A component command of USTRANSCOM, AMC's missions include: 
airlift support, air combat camera services, operational 
support airlift, and aeromedical evacuation. AMC is 
additionally responsible for the management of the Civil 
Reserve Air Fleet (CRAF) . The CRAF, which is composed of 
commercial aircraft, is committed in times of national 
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emergency to support the transportation of military forces and 
material worldwide. [Ref. 19:pp. 2C-21] 

3. Military Traffic Management Command 

The Military Traffic Management Command (MITCC) is the 
Department of Defense's global traffic manager responsible for 
acquiring the appropriate commercial transportation services 
for the movement of freight, personal property, and passengers 
to ensure rapid and timely movement in the continental United 
States (CONUS) and through most overseas ports. As DoD's 
traffic manager, MTMC provides the interface between DoD 
shippers and the civilian transportation industry, and is the 
sole worldwide negotiator with commercial carriers for rates, 
terms and conditions for a majority of DoD transportation 
requirements. In addition to providing this interface with 
commercial carriers, MTMC also provides an interface with 
military shippers and the Air Mobility Command (AMC), and the 
Military Sealift Command (MSC). [Ref. 20:p. 47] 

In relation to DoD's EDI implementation efforts in 
Defense Transportation, MTMC has been designated as the EDI 
Management Office for Defense Transportation. 

4. Military Sealift Command 

The Military Sealift Command (MSC) is the single 
operating agency and principal manager for Department of 
Defense ocean transportation. The primary mission of MSC is 
to provide sealift for strategic mobility in support of 
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national security objectives. In addition, MSC is tasked with 
direct fleet support and special mission support. In 
fulfilling these missions MSC operates a fleet of government 
owned and chartered U.S. flagships. This fleet includes fast 
sealift ships, maritime prepositioning ships, afloat 
prepositioning ships, ships of the Ready Reserve Force (RRF), 
as well as ships from the Naval Fleet Auxiliary Force (NFAF) 
and Special Mission Support Force assets. [Ref. 21:p. 22] 

B. SYSTEMS APPROACH: TRANSACTION SETS AND APPLICATION 

PROCESSES 

As discussed in Chapter V, the Department of Defense is 
committed to the implementation of electronic data interchange 
(EDI) as a means to improve economies and efficiencies in 
conducting business operations. One of the four functional 
areas identified by DMRD 941 as having the potential for 
significant savings and efficiency improvements resulting from 
the application of this technology was that of defense 
transportation. The purpose of an EDI system is to 
electronically link trading partners. In DoD's EDI pro^ 
for defense transportation, the trading partners include DoD 
shipping activities, the Military Traffic Management Command 
(MTMC), DoD finance centers, the General Services 

Administration (GSA), and commercial carriers. These 
communication linkages allow the exchange of business data 





such as tender/rate submissions, shipment information, and 
invoices. (Ref. 22:p. 3] 

DoD's implementation of EDI m defense transportation 
involves a systems approach which integrates several 
individual elements. These elements consist of individual 
transaction sets and the specific functional areas, or as 
addressed here, application processes to which they are 
applied, facilitating the electronic exchange information. 

1. Transaction Sets 

In an EDI environment it is through the use of 
transaction sets that information is electronically exchanged. 
Transaction sets provide the basis for defense transportation 
EDI implementation efforts by providing the required 
foundation for all EDI transactions. Current DoD 

transportation EDI capabilities are limited to the following 
ANSI ASC X12 transaction sets 10 : [Ref. 23: Annex 1 - page 1] 

• 110 - Air Freight Details and Invoice - X12.101. This 

transaction set is used by air freight carriers to submit 
information to DoD finance centers. This information 

relates to charges, discounts, and other details 
concerning the transportation services provided. 

• 210 - Motor Carrier Freight Details and Invoice - X12.104. 

This transaction set is used by motor carriers to submit 
information to DoD finance centers. This information 

relates to charges, discounts, and other details relating 
to the transportation services which the carrier provided. 


10 The format for these entries is: transaction set number, 
transaction set name, followed by the ASC X12 standard number. 
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• 214 - Motor Carrier Shipment Status Message - X12.106. 
Carriers use this transaction set to transmit shipment 
status information to applicable DoD shipping activities. 

• 410 - Rail Carrier Freight Details and Invoice - X12.139. 
This transaction set is used by rail carriers to submit 
information to DoD finance centers. This information 
relates to charges, discounts, and other details on the 
transportation services which the carrier provided. 

• 602 - Transportation Services Tender - X12.126. Carriers 

use this transaction set to submit rates and tender 
information to MTMC. These submissions include 

transmitting new tenders or amendments to existing tenders 
to MTMC. 

• 858 - Shipment Information - X12.18. This transaction set 
is used by DoD to transmit detailed shipment information. 
The data sent using this transaction set are found on the 
U.S. Government Bill of Lading, Standard Form 1103. 

• 859 - Freight Invoice - X12.55. This is a generic invoice 
used to transmit information relating to charges, 
discounts, and other details on the transportation 
services which the carrier provided. Although carriers 
may use any of the mode specific invoice transaction sets 
(110, 210, or 410), DoD is encouraging the use of the 859 
transaction set. 

• 994 - Administrative Message 11 . DoD uses this 

transaction set to provide freight carriers with 
information concerning the acceptance or rejection of 
tenders which they have submitted. For the acceptance or 
rejection notification for personal property carriers, 
transaction set 997 is used. 

• 997 - Functional Acknowledgment - X12.20. This 

transaction set is used to indicate if an EDI transmission 
is a valid ASC X12 transaction or not. Validity refers 
only to the transaction set's compliance with standard 
syntax requirements. Additionally, this transaction set 
is used to transmit notification of tender acceptance or 
rejection to personal property carriers. 


11 Transaction Set 994, Administrative Message, is a 
Transportation Data Coordinating Committee (TDCC) standard. 
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2. Application Processes 

The DoD's operating concept for electronically linking 
its shipping activities. DoD finance centers, MTMC, GSA, and 
commercial carrier trading partners involves primarily four 
processes: 

e Tender Submittal/Acceptance 

e Shipment Information (Government Bill of Lading) 
Generation and Distribution 

e Prepayment Auditing and Payment 

e Postpayment Auditing 

These processes form the foundation for electronically 
exchanging transportation related information and are critical 
elements for Defense transportation EDI initiatives. 

Before discussing the four primary application 
processes, it is necessary to comment on DoD finance centers. 
Currently there are three DoD transportation payment centers: 
1) Defense Finance and Accounting Service, Indianapolis Center 
(DFAS-IN), which processes and pays transportation bills for 
the Army, Air Force, and DLA; 2) the Marine Corp's 
Transportation Voucher Certification Branch (TVCB), Albany, 
responsible for Marine Corps transportation payment; and 3) 
the Navy Material Transportation Office (NAVMTO), Norfolk, 
responsible for processing and paying Navy transportation 
bills. Although all three of these payment centers are 
currently paying transportation bills for their respective 
service, DFAS-IN is instrumental to DoD operating in an EDI 







environment. The eventual plan for the defense transportation 
EDI operating environment includes the consolidation of all 
transportation related payment functions at DFAS-IN. This 
initiative will be further addressed in the Future/Proposed 
Enhancements section of this chapter under the discussion of 
the Defense Transportation Payment System (DTRS 12 ). [Ref. 
24:p. 3] 

a. Tender Submittal/Acceptance 

The Department of Defense Standard Tender of 
Freight Services (MT Form 364-R) is used by commercial 
carriers to submit rates, under which they propose to move DoD 
cargo, to MTMC. Once received by MTMC, the information 
provided by the tender is used for transportation pricing, 
carrier selection, auditing, and payment. 

MTMC's paper-based standard tender document 
processing operation typically involves the daily receipt of 
nine copies each of up to 100 paper tenders. Each tender must 
be reviewed for accuracy and then distributed to MTMC's Area 
Commands and the General Services Administration. This 
process involves numerous handling operations and repeated 
data entry into multiple computer systems. [Ref. 25:p. l-l] 


12 According to the Transportation Operations Directorate, 
Systems Management Office (DFAS-IN-TA) , of the Defense Finance and 
Accounting Service-Indianapolis Center, DTRS is used as the acronym 
for the Defense Transportation Payment System because the acronym 
DTPS was used for another system. 
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In submitting tenders electronically to WTMC, the 
carrier submits their proposed tender using the ASC X12 
transaction set 602—Transportation Services Tender. Once 
received, MTMC's computers analyze the tender for conformance 
to established tender rules and regulations. If the tender 
satisfies this check it is accepted and a tender acceptance 
message is automatically transmitted to the carrier, using 
transaction set 994—Administrative Message for freight 
carriers, and transaction set 997—Functional Acknowledgment 
for personal property carriers. Once received and accepted, 
the tenders are distributed to GSA for use in postpayment 
auditing. Transaction set 994 {and 997 where appropriate) is 
also used if the tender is rejected, and will include the 
reason for rejection. [Ref. 25:p. 1-2] 

Currently, carrier submission of electronic tenders 
is limited to voluntary tenders; guaranteed traffic and other 
negotiated tenders must continue to be submitted in paper 
format. As of January 1994, 44 carriers were electronically 
submitting 35 percent of all voluntary tenders filed with 
MTMC. [Ref. 26]. At present, electronic tender submission is 
also limited to motor and rail carriers, with other 
transportation modes to be added in the future [Ref. 27:p. 
20 ] . 

The major benefit derived from electronic tender 
submission is the decrease in time required for the tender 
acceptance process. When submitting paper tenders, a carrier 
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may have to wait two to three weeks for approval. With EDI 
and electronic submission, the turnaround time is reduced to 
48 hours. [Ref. 27:p. 20] 

b. Shipment Information 

The Government Bill of Lading (GBL) is the primary 
document used by the Department of Defense for procuring 
transportation services. Two types of GBLs are used by DoD, 
freight and personal property, with DoD shippers generating 
approximately 1.5 million freight and 800 thousand personal 
property GBLs annually. Since the GBL is a seven part form, 
this can result in over 45,000 pieces of paper a day being 
distributed among carriers, MTMC, and receivers (consignees). 
The utilization of EDI drastically reduces this volume of 
paper and the associated manual processing. [Ref. 28:p. 1-2] 

In an EDI operating environment, a DoD shipping 
activity uses an automated system to generate a GBL. Once 
generated, the shipping activity transmits the shipment 
information to the carrier, all consignees, and MTMC using the 
ASC X12 transaction set 858, Shipment Information. Even with 
these electronic exchanges, paper is still required. Serving 
as an intransit manifest and as proof of service for payment, 
the original paper GBL will be given to the commercial 
carrier's driver, with a signed paper copy of the GBL being 
retained by the shipping activity. [Ref. 22:p. 6] 
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c. Prepayment Auditing and Payment 


One of the recipients of the electronically 
transmitted shipment information is MTMC. Upon receipt of 
this information, MTMC verifies that a valid tender exists for 
the carrier. If a tender does not exist, MTMC rejects the 
shipment and notifies the originating DoD shipping activity. 
If a valid tender exists, MTMC creates an electronic record of 
the shipment and transmits rated shipment information to the 
Defense Finance and Accounting Service, Indianapolis Center 
(DFAS-IN) using transaction set 858, Shipment Information. 
[Ref. 30:p. 2] 

Following delivery, the commercial carrier submits 
invoices electronically to DFAS-IN using transaction sets 110, 
210, 410, or 859, which are the Air Freight Details and 
Invoice, Motor Carrier Freight Details and Invoice, Rail 
Carrier Freight Details and Invoice, and the Freight Invoice 
respectively. Prior to payment DFAS-IN audits the invoice by 
matching rated shipment information with the appropriate 
invoice and reconciling any differences. [Ref. 22:p. 6] 

Following the audit and reconciliation process, 
DFAS-IN pays the carrier for the services performed. The 
actual amount paid is the lesser of the amount on the shipment 
information record or on the invoice. Lastly, DFAS-IN 
completes the record for the shipment by sending payment 
information to MTMC and also sending invoice, payment, and 
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shipment information to the General Services Administration 
for postpayment auditing. 

d. Postpayment Auditing 

Upon receipt of invoice, payment, and shipment 
information from DFAS-IN, the General Services Administration 
performs postpayment auditing. In performing the postpayment 
audit, GSA also uses the accepted tender submission which it 
had previously received from MTMC. [Ref. 31] 

C. DEFENSE TRANSPORTATION EDI OPERATING CONCEPT 

Through the electronic exchange of information among 
shipping activities, commercial carriers, the Military Traffic 
Management Command, Defense Finance and Accounting Service - 
Indianapolis Center, and the General Services Administration, 
DoD hopes to achieve increased economies and efficiencies in 
defense transportation operations. The realization of this 
goal involves the successful integration of the previously 
discussed application processes. The comprehensive nature of 
DoD's approach to the implementation of EDI in defense 
transportation is summarized in two predominant operating 
concepts: 

• Defense Transportation EDI Operating Concept: Freight 
[Ref. 22:p. 5] 

• Defense Transportation EDI Operating Concept: Personal 
Property [Ref. 32:p. 1-3] 
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Though conceptually similar, the operating concepts 
applicable to freight and personal property are discussed 
separately. To help clarify the discussion of these EDI 
operating concepts, Figure 20 depicts the data flow format 
conventions that are used in the accompanying figures 
highlighting the data flow identification numbers and EDI 
transaction sets. For example in Figure 20, the first data 


flow shows the carrier submitting tenders to MTMC using 
transaction set 602. This is followed by data flow number 
two, which is MTMC's tender acceptance/rejection and is 



Figure 20 Operating concept data flow format convention 


1. Defense Transportation EDI Operating Concept: Freight 

The Department of Defense's EDI operating concept for 
electronically linking freight carriers, MTMC, Defense 
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shipping activities, DFAS-IN, and GSA is depicted in Figure 
21. This operating concept depicts an overall systems 
approach to integrating the rate and tender submittal, 
shipment information, prepayment audit and payment, and 
postpayment audit application processes. 

a. CONUS Freight Management System 

An integral component of DoD's freight EDI 
operating concept is MTMC's CONUS Freight Management (CFM) 
system. The CONUS Freight Management system is DoD's 
centralized automated freight traffic management system for 
domestic freight movement. As the centralized information 
management system, CFM performs six primary functions: l) 
routing of domestic freight shipments, 2) supporting 
prepayment audits of GBLs, 3) providing rate-quoting services, 
4) monitoring commercial freight carrier performance, 5) 
monitoring the overall efficiency of the domestic freight 
traffic system, and 6) supporting the Joint deployment 
community during contingencies [Ref. 33:pp. 2-5 - 2-7]. 

The CFM system data base contains rate and shipment 
information derived from the U.S. Government Bill of Lading 
(GBL) (Standard Form 1103) and the Department of Defense (DoD) 
Standard Tender of Freight Services (MT Form 364-R). The CFM 
system has the capability to receive this data from three 
sources: 1) CFM field modules (currently 53 shipping 
activities are on-line); 2) shipper services interfacing 
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Figure 21 Defense Transportation EDI Operating Concept 
Freight 










systems 13 ; and 3) the Defense Transportation Payment System 
(DTRS). [Ref. 34:pp. 14-15] 

The CFM system provides the information data base 
necessary for establishing an effective EDI operating 
environment for DoD freight transportation operations. It is 
the application of EDI that allows MTMC (CFM) to 
electronically transmit rate and payment data among freight 
carriers, DoD shippers, and DFAS-IN. 

Jb. Freight Operating Concept Data Flows 

Descriptions of the data flows associated with the 
DoD EDI freight operating concept depicted in Figure 21 
follow: [Ref. 22:pp. 5-7] 

• Data Flow l: A commercial carrier submits electronic 

tenders (proposed rates) for transportation services to 
the Military Traffic Management Command (MTMC). 

• Data Flow 2: Upon receipt of the electronic tenders, 

MTMC's computers analyze the tenders for accuracy and 
conformance to established rules and regulations. After 
this review MTMC will transmit a tender acceptance or 
rejection message to the submitting carrier. 

• Data Flow 3: Accepted tenders are electronically 

transmitted to the General Services Administration (GSA). 

• Data Flow 4: DoD shipping activities, which create the 
GBL, transmit the shipment information contained on the 
GBL to MTMC. 


13 CFM shipper services interfacing systems include: Cargo 
Movement Operations System (CMOS), Defense Transportation Tracking 
System (DTTS), Integrated Booking System (IBS), Transportation 
Management system (TMS), Worldwide Port System (WPS), and the 
Global Transportation Network (GTN). 
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• Data Flow 5: DoD shipping activities, which create the 
GBL, transmit the shipment information contained on the 
GBL to the applicable freight carrier (if desired). 

• Data Flow 6: DoD shipping activities have the capability 
to electronically receive shipment status information from 
the carrier. 

• Data Flow 7: Using the received and accepted tenders, 
MTMC provides rated shipment information to DFAS-IN. 

• Data Flow 8: After delivery of the freight, the carrier 
transmits the appropriate invoice to DFAS-IN. 

• Data Flow 9: Upon receipt of the invoice, DFAS-IN 

performs a prepayment audit, matching rated shipment 
information with the appropriate invoice. Once complete, 
DFAS-IN provides MTMC with the cost information, which 
completes the shipment record. 

• Data Flow 10: The DoD process for paying freight carriers 
for transportation services is currently a manual process. 

• Data Flow 11: After payment, DFAS-IN provides payment 
information (often referred to as remittance advice) to 
the freight carrier. This transaction includes such 
information as notification of payment, payment amount and 
the applicable invoice for which payment is being made. 

• Data Flow 12: Lastly, DFAS-IN provides payment 

information to GSA for postpayment audit. 


2. Defense Transportation EDI Operating Concept: Personal 
Property 

When applied to the transportation aspects of DoD's 
personal property program, the EDI operating concept involves 
electronically linking personal property carriers, MTMC, 
Defense shipping activities, DFAS-IN, and GSA. As with the 
freight EDI operating concept, EDI in the personal property 
environment consists of the integration of the rate and tender 
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submittal, shipment information, prepayment audit and payment, 
and postpayment audit application processes. 

In developing the personal property EDI operating 
concept, EDI technology was applied to the Military Traffic 
Management Command's Transportation Operational Personal 
Property Standard System (TOPS) and the Worldwide Household 
Goods Information System For Transportation (WHIST). These 
automated management information systems provide the 
information base for establishing an effective EDI operating 
environment for personal property transportation operations. 
[Ref. 3 2:pp. 1-2 - 1-3] 

a. Transportation Operational Personal Property 
Standard System 

The Transportation Operational Personal Property 
Standard System (TOPS) is a DoD-wide information management 
system which automates operations at the Personal Property 
Shipping Office (PPSO) level. TOPS was developed to assist 
Personal Property Shipping Offices by eliminating the 
extensive manual processing of personal property shipment 
information. This system automates the gathering, exchange, 
and maintenance of personal property information for outbound 
and inbound personal property shipments. In addition to 
capturing and processing personal property data, TOPS is the 
information distribution link between personal property 
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offices and the Worldwide Household Goods Information System 
For Transportation (WHIST). [Ref. 35:pp. 10-13] 

Jb. Worldwide Household Goods Information System for 
Transportstion 

The Worldwide Household Goods Information System 
for Transportation (WHIST) is DoD's central personal property 
transportation data base. The purpose of WHIST is to collect, 
process, and maintain carrier-filed rate as well as shipment 
information supplied by TOPS. WHIST provides shipment 
transportation and rate information to DFAS-IN and to other 
DoD activities to support their personal property information 
requirements. [Ref. 36:pp. 1-1 - 1-2] 

c. Personal Property Operating Concept Data Flows 
As depicted in Figure 22, the TOPS and WHIST 
systems perform vital functions involving the capturing, 
processing, and distribution of business information necessary 
to initiate, monitor, and manage DoD's personal property 
shipment system. A description of the requisite data flows 
associated with this operating concept is as follows: [Ref. 
37] 

• Data Flow 1: A personal property carrier submits 

electronic tenders (proposed rates) for transportation 
services to WHIST in response to a Military Traffic 
Management Command (MTMC) solicitation. 

• Data Flow 2: Upon receipt of the electronic tenders, 

MTMC's computers analyze the tenders for accuracy and 
conformance to established rules and regulations. After 
this review MTMC will transmit a tender acceptance or 
rejection message to the submitting carrier. Where the 
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Figure 22 Defense Transportation EDI Operating Concept: 

Personal Property 
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freight EDI operating concept utilized transaction set 
994—Administrative Message to convey acceptance or 
rejection of tenders, here transaction set 99 7—Functional 
Acknowledgment is used. 

• Data Flow 3: The WHIST data base provides rate 

information to TOPS. This electronic transmission is 
accomplished through the use of a wide area network (WAN) . 

• Data Flow 4: The WHIST data base also provides rate 

information to DFAS-IN through the electronic transmission 
of a flat file. 

• Data Flow 5: In addition to providing rate information to 
TOPS and DFAS-IN, WHIST also provides this information tc 
GSA. The conveyance of rate information to GSA is 
accomplished through paper means. 

• Data Flow 6: This data flow depicts the initial interface 
between a DoD shipper of personal property and the 
personal property movement system. To initiate the 
shipment, the DoD customer interfaces with the personal 
property system through TOPS at the appropriate PPSO. 

• Data Flow 7: TOPS gathers the shipment information from 
the DoD user and transmits the information to WHIST. As 
was the case with the transmission of rate information 
between TOPS and WHIST, this data flow is electronic with 
the information using a WAN instead of EDI. 

• Data Flow 8 and 9: WHIST, which creates the GBL using the 
information provided by TOPS, transmits shipment 
information to the applicable personal property carrier 
and to DFAS-IN. 

• Data Flow 10: After delivery of the shipment to storage 
or a residence, the carrier receives shipment information 
from WHIST for use in generating the invoice. The carrier 
then transmits the appropriate invoice to DFAS-IN for 
payment. 

• Data Flow 11: Upon receipt of the invoice, DFAS-IN 

performs a prepayment audit, matching rated shipment 
information with the appropriate invoice. Once complete, 
DFAS-IN pays the carrier. As with payment for freight 
carriers, DoD's process for paying personal property 
carriers is currently a manual process. 

• Data Flow 12: DFAS-IN provides WHIST with cost 

information, currently provided using paper as the medium 
of exchange, which completes the shipment record. 
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• Data Flow 13: After payment, DFAS-IN provides payment 
information (often referred to as remittance advice) to 
the personal property carrier. This transaction includes 
such information as notification of payment, payment 
amount and the applicable invoice for which payment is 
being made. 

• Data Flow 14: Lastly, DFAS-IN provides payment 

information to GSA for postpayment audit. 


3. Future/Proposed Enhancements 

The preceding discussion of the DoD EDI operating 
concepts for defense transportation primarily involved the 
current status of these initiatives. DoD's commitment to EDI 
is long-term and the EDI operating environment is continually 
evolving. Four of the principal future enhancements for 
defense transportation include: 

• Defense Transportation Payment System 

• Electronic Funds Transfer 

• Transaction Set 820, Payment Order/Remittance Advice 

• Electronic Submission of Guaranteed Traffic Tenders 


a. Defense Transportation Payment System (DTRS) 

The defense transportation EDI operating concept 
involves the implementation of electronic data interchange to 
the maximum extent possible. As depicted in Figures 21 and 
22, the prepayment auditing and carrier payment processes 
still involve labor intensive manual processing. Each year 
approximately 85 percent (l.l million) of the 1.3 million 
annual total DoD CONUS freight shipments are transported by 
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motor carriers, 12.5 percent :0.2 million) by air freight 
carriers, 1.5 percent (20,000i by rail carriers, and less than 
l percent by others. DLA is the principal DoD shipper 
accounting for 45 percent 14 of the total. DLA is followed 
by the Army with 24 percent, the Air Force with 17 percent, 
the Navy with 12 percent, and the Marine Corps with 2 percent. 
[Ref. 3 3:pp. 3-3 - 3-4] 

The Offense Finance and Accounting Service 
Indianapolis Cen -r (DFAS-IN), is DoD's largest transportation 
payment center, annually processing over a million frei 
personal property, and travel-related bills for the Army, Air 
Force, and Defense Logistics Agency. The existing prepayment 
auditing and payment processes are labor intensive and involve 
time consuming manual handling of shipment information 
documents. To eliminate the costs and inefficiencies 
associated with the existing system, DoD is in the process of 
implementing the Defense Transportation Payment System (DTRS) 
at DFAS-IN. 

The Defense Transportation Payment System is an 
initiative which will use EDI technology in a paperless 
environment, enhancing the transportation payment, collection, 
accounting, and reporting functions. The DTRS concept will 
allow DFAS-IN: [Ref. 38:p. 1] 

14 This total includes the Defense Contract Administration 
Service shipping (DCAS). The actual breakdown between is that DLA 
accounts for 34 percent with DCA= accounting for 11 percent. [Ref. 
33:pp. 3-3 - 3-4] 
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• To electronically receive government bills of lading 
(GBLs) and shipment cost data from EDI-capable shipping 
activities. 

• To receive electronic invoice information from EDI-capable 
carriers. 

• To pay carriers through electronic funds transfer (EFT). 

• To consolidate all DoD transportation payment functions at 
DFAS-IN. 


The Defense Transportation Payment System is a long 
term initiative which will be implemented in four increments: 
[Ref. 39: chart 2] 

• Increment I: The focus of Increment I includes: 1) 

automating the receipt of invoices and shipment 
information, 2) automating the processing of payments, 3) 
interfacing electronically with GSA, MTMC, and carriers. 

• Increment II: Increment II addresses the automation of 
claims processing and the integration of claim, invoice, 
payment, and collection functions. 

• Increment III: In Increment III, DTRS will implement the 
capability to process shipment information, invoices, and 
payments for personal property shipments. Additionally, 
increment III will result in DTRS interfacing with the 
Standard Disbursing and Accounting System, automating fund 
disbursement, and implementing electronic fund transfer 
(EFT) technology to transmit payments to carriers. 

• Increment IV: Navy and Marine Corps transportation 

payment requirements will be consolidated at DFAS-IN 
during Increment IV. 


The Defense Finance and Accounting Service- 
Indianapolis Center is continuing with the implementation of 
increment I of the DTRS initiative. Currently DFAS-IN is 
limited to the receipt and processing of guaranteed traffic 
shipment information associated with the Defense Logistics 
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Agency !DLA) Defense Distribution Depot at Ogden, Utah. The 
next two shipping activities planned to be linked with DFAS-IN 
will be the Defense Construction Supply Center, Columbus, Ohio 
and the Defense Depot located m Memphis, Tennessee. Other 
milestones for the implementation of DTRS include a FY 94 
target for capability to exchange electronic transactions with 
personal property carriers, and to have all the transportation 
payment functions consolidated at DFAS-IN (increment IV) 
during FY 95. [Ref. 40] 

Jb. Electronic Funds Transfer 

Electronic Funds Transfer (EFT) is "...the 
electronic transfer of value, meaning the debiting of one 
account and the crediting of another" [Ref. 2:p. 217]. As 
applied to DoD transactions, EFT includes the actual payment 
(transfer of value) as well as the exchange of payment and 
remittance information. 

The concept and use of electronic funds transfer is 
not new to the Department of Defense. DoD has for many years 
used EFT to deposit pay and benefits directly into individual 
bank accounts, resulting in an increase in productivity of 
personnel and a reduction in the cost of correcting errors and 
replacing lost checks. However, paying transportation vendors 
is a new EFT application for the DoD. [Ref. 41:p. 1-1] 

As mentioned above, DoD implementation of EFT for 
defense transportation is included in the DTRS Increment III. 
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c. Transaction Set 820, Payment Order/Remittance 
Advice 

Currently the transportation payment centers (DFAS- 
IN) do not have the capability to utilize the 820 transaction 
set. As suggested in both the freight and personal property 
EDI operating concepts, when the operational capability 
exists, transaction set 820 will be used by DFAS-IN to 
transmit payment information, also referred to as remittance 
advice, to MTMC, the carrier, and to GSA. These transmissions 
will indicate that payment for an invoice has been made, the 
amount of the payment, the purpose of the payment, and any 
additional information relating to the adjustment of the 
invoiced amount. 

d. Electronic Submission of Guaranteed Traffic 
Tenders 

Another planned future enhancement to DoD's EDI 
transportation operating concept is the capability for 
receiving the electronic submission of tenders for guaranteed 
traffic. As previously discussed, at present carriers are 
limited to the electronic submission of voluntary tenders. In 
contrast to these voluntary submissions, MTMC's Inland Traffic 
Negotiations Division (MT-INN) solicits tenders from carriers 
to meet specific movement requirements. These solicitations 
are made through the guaranteed traffic (GT) program and 
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currently account for over 40 percent of Defense shipments. 
[Ref. 42:p. 1-1] 

The current, labor-intensive, time consuming manual 
methods for processing guaranteed traffic solicitations and 
tenders involves four distinct steps: 1) a DoD shipper submits 
a traffic movement requirement to MT-INN, who then develops a 
solicitation to satisfy the requirement (presolicitation 
phase); 2) MT-INN advertises the solicitation and receives 
proposed rates from carriers in the form of tender bids 
(solicitation phase); 3) after receipt of the tender bids, MT- 
INN conducts an evaluation to determine the carriers offering 
the lowest cost rates (evaluation phase); 4) lastly, MT-INN 
will award the traffic to the carrier offering the lowest cost 
rates, and will publish and distribute those rates as GT 
tenders (award phase). [Ref. 42:p. 2-2] 

As with other labor intensive document processing, 
the GT program has the potential for significant improvements 
in economies and efficiencies if the manual procedures can be 
replaced by electronic processing. The application of EDI to 
the GT program is currently undergoing test and evaluation 15 . 


15 For further details on the proposed electronic submission 
of guaranteed traffic tenders see "An Electronic Commerce Strategy 
for frTTMC's Guaranteed Traffic Program," Logistics Management 
Institute, Report MT901R1, October 1992. 
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D. ADDITIONAL DEFENSE TRANSPORTATION ELECTRONIC DATA 

INTERCHANGE INITIATIVES 

In addition to the specific EDI projects which are an 
integral part of the overall Defense transportation EDI 
operating concept (e.g., CFM, TOPS, and WHIST), there are 
numerous other initiatives underway. These efforts include 
projects designed to interface with the freight and personal 
property EDI operating concepts as well as those which are 
more service-specific in nature. Discussed below are some of 
the principal efforts currently being undertaken. 

1. Cargo Movement Operations System 

The Cargo Movement Operations System (CMOS) is the Air 
Force's response to the 1987 Joint Chiefs of Staff (JCS) 
requirement for the Transportation Coordinators' Automated 
Information Movement System (TCAIMS) 16 . CMOS automates base- 
level transportation processes focussing on achieving greater 
efficiency in operations as well as providing In-Transit 
visibility (ITV) of cargo and unit passenger movements. 
Current CMOS capabilities include: 1) automation of all air 
and surface freight operations, 2) advance shipping notice to 
other CMOS sites, 3) automated financial accounting, 4) 
standardized transportation information processing, and 5) 
interfaces with the CONUS Freight Management system. [Ref. 43] 


16 TCAIMS is a generic term for the hardware, software, 
procedures, and related systems that provide integration of the 
movement information used in the force deployment process. 


107 






2. Advanced Arrival Notification Interface 

Currently in the development stage, the Advance 
Arrival Notification Interface is an Army system which will 
allow MTMC ports to receive import arrival notifications from 
ocean carriers and cargo release notification from customs. 
The primary transaction set involved with this transmission of 
information is transaction set 312, Arrival Notice for Ocean 
Carriers. [Ref. 44] 

3. Worldwide Port System 

An Army system, the Worldwide Port System (WPS) is an 
automated information management system designed to enhance 
MTMC's terminal management and cargo documentation mission. 
The predominant role of WPS is to support the peacetime and 
wartime tracking and documenting of DoD cargo moving via 
common user ocean transportation, while maintaining in-transit 
visibility. [Ref. 45:pp. 18-19] 

4. Transportation Discrepancy Report 

The automation of the Transportation Discrepancy 
Report (TDR) is a MTMC program designed to allow consignees to 
record discrepancies and transfer the data electronically to 
the CFM host system. Upon receipt, the CFM host will 
distribute the electronic TDR in EDI format to the appropriate 
claims offices of the military services, to the shipper, DoD 
finance center, and the carrier. The TDR effort will utilize 
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transaction set 842, Nonconformance Report, and at present is 
in the late development phase (Ref. 46] 

5. Transportation Management System 

The Transportation Management System (TMS) is a system 
developed by the Marine Corps and adopted by the Navy for 
automating the GBL process. The Marine Corps developed the 
system as part of the Office of the Secretary of Defense (OSD) 
sponsored project for GBL automation. TMS automates the 
generation of GBLs and translates the information to the 
required EDI format for transmission using transaction set 
858, Shipment Information (e.g., to MTMC and the Navy Material 
Transportation Office (NAVMTO)). In addition, TMS is capable 
of receiving EDI transactions for inbound GBLs and invoices, 
automatically validates invoices against the original GBL, and 
transfers payment information to the transportation payment 
center. [Ref. 47:p. 3-11] and [Ref. 48] 

6. Transportation Operation Management 

The Transportation Operation Management (TOM) system 
is a Navy-proposed system, currently in the development stage, 
designed to improve NAVMTO management of transportation 
operations. The TOM system will be an integrated information 
system whose data base will support in-transit visibility, 
cargo routing, and movement authorization for all Navy 
shipments. The TOM system will exchange information using 
transaction sets 214 (Shipment Status Message) , 856 (Ship 
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Notice/Manifest), and 858 (Shipment Information). [Ref. 49:p. 
3-6] 

7. Do-It-Yourself EDI Automated Loading System 

The Do-It-Yourself EDI Automated Loading System 
(DEALS) is a Navy-sponsored program planned to replace the 
current system which supports Do-It-Yourself (DITY) moves of 
household goods. DEALS will automate the Application for DITY 
Move and Counseling Checklist (DD Form 2278) , Application for 
Non-Temporary S~orage (DD Form 1164), and Travel Voucher (DD 
Form 1351-2) and then transmit this information electronically 
to NAVMTO using transaction set 858, Shipment Information. 
[Ref. 49:pp. 3-6 - 3-7] 

8. Household Goods EDI Audit Transactions 

Another Navy project, the Household Goods EDI Audit 
Transactions (HEAT) project was developed to improve the 
auditing of household goods movements. Initially, HEAT 
focussed on automating the Application for Shipment and/or 
Storage of Personal Property (DD Form 1299), the document 
which authorizes personal property shipments and enables 
NAVMTO auditors to determine whether payments have been made 
for all shipments related to a particular member's relocation. 
The HEAT concept replaces the Personal Property Shipping 
Office's manual submission of DD Form 1299 with electronic 
transmission using transaction set 858, Shipment Information. 
[Ref. 49:p. 3-7] 
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9. Defense Transportation Tracking System 

The Defense Transportation Tracking System (DTTS) data 
base is maintained at the Naval Material Transportation Office 
(NAVMTO) located in Norfolk, VA. Currently the system is in 
the test and development stage, with the capability of 
communication with the Red River Army Depot (the 
implementation plan is to have all applicable shippers on-line 
within one year). This system uses satellite technology to 
track and monitor shipments of arms, ammunition, and 
explosives transported throughout the Continental United 
States (CONUS) by commercial carriers. To establish the 
requisite data base record before satellite tracking can 
occur, carriers must submit shipment information to DTTS. The 
application of EDI technology to this system will allow for 
the electronic submission of shipment information using 
transaction set 85b, Shipment Information. [Ref. 49:p. 3-6] 

E. ASSOCIATED DEFENSE TRANSPORTATION ELECTRONIC DATA 
INTERCHANGE ISSUES 

1. Telecommunications Architecture 

Figure 23 depicts the defense transportation EDI 
telecommunications architecture. As shown, this 

communications infrastructure consists of three separate modes 
for connecting trading partners: 1) a value added network 
(VAN), 2) direct leased lines, or 3) the Defense Data Network 
(DDN) or the NAVSUP Logistics Network (NLN). 
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Figure 23 Defense transportation EDI telecommunications 
architecture 


Value added network services for defense 
transportation are currently provided by Sprint 17 . Sprint 
is under contract with GSA as the official DoD transportation 
VAN to be used for EDI communications originating within DoD 
for transmission to non-DoD activities. While Sprint is the 
required VAN for DoD-originated transactions, DoD's commercial 
trading partners are free to use the VAN of their choosing as 

17 While Sprint is the official DoD transportation VAN, MTMC 
is currently using AT&T EasyLink for some of their VAN 
requirements. 
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long as it has the capability to communicate with the EDI VAN 
used by DoD (currently Sprint;. 

Due to the high volume of information transmitted 
among MTMC, GSA, and DFAS-IN (current and planned volume), 
direct lines are leased from local telephone providers. For 
a majority of the remaining information traffic (intra-DoD), 
DDN is used to link the various Service, DLA, and MTMC sites 
to one another. The remaining mode, the NAVSUP Logistics 
Network, is used for EDI communications within the Navy. 

2. Barriers to Defense Transportation Electronic Data 

Interchange Implementation 

The implementation of electronic data interchange and 
the resulting transition to a paperless environment represents 
a significant change to the traditional way the Department of 
Defense conducts business. As is often the case with the 
introduction of new actions, methods and ideas, the 
application of EDI technology to defense transportation 
operations has, and is, experiencing resistance. In examining 
DoD's implementation of EDI to the processing of defense 
transportation information, four predominant instances of 
resistance (barriers) to the efficient implementation of 
electronic data interchange include: 

• Lack of knowledge and/or understanding 

• Decentralization of effort 

• Cost-benefit analysis and resourcing 
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a. Lack of Knowledge and/or Understanding 

When considering the implementation of EDI it is 
important to understand that electronic data interchange is a 
technology, a way of doing business, and not a specific 
system. As Michael Hammer discusses in "Reengineering Work: 
Don't Automate, Obliterate": [Ref. 50:pp. 104-112] 

It is time to step paving the cow paths. Instead of 
embedding outdated processes in silicon and software, we 
should obliterate chem and start over. We should 
"reengineer" our businesses: use the power of modern 
information technology to radically redesign our business 
processes in order to achieve dramatic improvements in 
their performance. 

Those involved with the application of EDI 
technology must realize that introducing EDI to obsolete and 
inefficient processes will not necessarily result in improved 
performance or increased efficiencies. The appropriate 
questions can no longer solely be "Can a particular process be 
adapted to EDI techniques?" and if yes, "How to go about it?", 
but must now include "Why are we doing business in the current 
manner?" and "In its present format, should EDI be applied to 
this process?" 

b. Decentralization of Effort 

Although EDI is a major DoD initiative, its 
development and implementation has been largely left up to che 
discretion of the individual services. This decentralized 
approach to implementation has resulted in: 1) varying levels 
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of importance placed on EDI among the services, 2) the 
sporadic fielding of EDI projects, 3) the uneven distribution 
of personnel with EDI expertise, and 4) in many cases ; the 
duplication of effort among activities, and the resulting 
additional expenditure of scarce resources. 

c. Cost-benefit Analysis and Resourcing 

As available resources continue to diminish, there 
is greater competition for funding among DoD programs. As a 
result, it is becoming increasingly more difficult for 
individual programs to justify DoD commitment of resources in 
support of their efforts. One of the potential problems 
facing DoD EDI programs is the nature of the potential 
benefits. As reported in DMRD 941 it is expected that the 
indirect benefits of EDI implementation will be more 
significant than the direct benefits. A possible obstacle 
here is associated with the potential for subjectivity and the 
resulting difficulty in identifying what the actual 
(anticipated) indirect benefits are (will be) . Additionally, 
many of the benefits associated with EDI implementation are 
intuitive and intangible in nature, making the quantification 
of any related cost savings more difficult. The potential 
difficulties in identifying and quantifying actual cost 
related savings resulting from EDI implementation may make it 
increasingly more difficult to obtain resources. 
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d. Standardization 

The Department of Defense has mandated that 
activities shall use the ANSI ASC X12 standard for conducting 
EDI transactions. While this significantly improves the 
potential for the efficient exchange of information, the use 
of the X12 standard is only part of the solution. Once the 
individual transaction secs are identified, the corresponding 
data must be mapped to the appropriate EDI format. 
Coordinated efforts must continue between trading partners to 
standardize the data mapping along with the corresponding 
implementation convention to further ensure that EDI 
information exchange is optimized. 

F. CHAPTER SUMMARY 

This chapter has focused on the application of electronic 
data interchange to defense transportation operations. As 
discussed in Chapter V, transportation was one of the four 
functional areas identified by DMRD 941 as having the 
potential for significant savings and efficiency improvements 
resulting from the application of EDI technology. Through the 
electronic exchange of information among its trading 
partners 13 , DoD hopes to achieve increased economies and 


18 The Department of Defense's trading partners for the 
electronic exchange of information pertaining to defense 
transportation operations include: DoD shipping activities, the 
Military Traffic Management Command (MTMC) , the Defense Finance and 
Accounting Service, Indianapolis Center (DFAS-IN), :r.e General 
Services Administration (GSA), and commercial >:\rriers. 
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efficiencies in defense transportation operations. DoD's 
implementation of EDI in defense transportation involves a 
systems approach which integrates several functional area 
application processes as well as the individual transaction 
sets used for the actual electronic exchange of information. 
The comprehensive nature of DoD's approach to the 
implementation of EDI in defense transportation is summarized 
in two predominant operating concepts: l) Defense 
Transportation EDI Operating Concept-HFreight and 2) Defense 
Transportation EDI Operating Concept—Personal Property. 

Reflecting DoD's long-term commitment to EDI, four of the 
principal future enhancements for defense transportation were 
discussed: 1) Defense Transportation Payment System, 2) 
Electronic Funds Transfer, 3) Transaction Set 820, Payment 
Order/Remittance Advice, and 4) Electronic Submission of 
Guaranteed Traffic Tenders. 

In addition to the specific EDI projects which are an 
integral part of the overall Defense transportation EDI 
operating concept (e.g., CFM, TOPS, and WHIST), there are 
numerous other initiatives underway. These efforts include 
projects designed to interface with the freight and personal 
property EDI operating concepts as well as those which are 
more service specific in nature. 
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VII. SUMMARY AMD CONCLUSIONS 

A. SUMMARY 

Communications and the exchange of information are 
critical elements for a majority of the activities in which 
organizations engage. Historically, organizations have 
typically relied exclusively on paper for conducting business 
transactions and exchanging information among business 
partners. Although proven to be effective and convenient, 
paper may no longer be the most efficient medium for 
conducting business transactions. Advances in computers, 
communication, and electronic technology have provided a 
variety of alternative information processing techniques, 
which allow information to be processed faster, more 
accurately, and at a lower cost than similar manual, paper- 
based, processing systems. 

One such method is Electronic Data Interchange (EDI) . 
Electronic data interchange is the inter-organizational, 
computer-to-computer exchange of business documentation and 
information in a standardized, machine-processable format. It 
is important to understand that EDI is a technology, a way of 
doing business, and not a specific system. The implementation 
of EDI involves more than just the automation of existing 
processes. Electronic data interchange provides the 
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opportunity to revise existing information handling methods 
which can result in improved performance, economies, and 
efficiencies in operations. The primary purpose of EDI is to 
make business processes more efficient by enhancing 
information management through the replacement of paper with 
electronic equivalents. 

The computer-to-computer exchange of information is not 
new to American industry or to the Department of Defense. 
Since the 1960s, private companies and DoD activities have 
been exchanging business information electronically. A major 
characteristic, and drawback, of these early data exchange 
arrangements was the use of many different non-standard and 
proprietary data formats. 

The development of standard data formats, also referred to 
as "standards," played an important role in the development 
and acceptance of EDI technology. Prior to the development of 
standardized formats, organizations may have needed different 
computer systems or applications for each customer, or trading 
partner, with which it wished to electronically communicate. 
Standardization eased the electronic exchange of data and 
encouraged the use of EDI technology by providing a uniform 
method for configuring unstructured data into a structured 
format. This structuring and standardization of data format 
allows computers to transfer, read, understand and process 
information automatically, without additional human 
intervention. 
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By providing a common language for the electronic exchange 
of information, the standards eliminate the need to develop 
special software for each trading partner's unique data 
format. This, in turn, allows the use of one software package 
to generate transactions in a format appropriate for the 
exchange of information between multiple trading partners. 

When discussing EDI data format standards, keep in mind 
that: 

• Compliance with the standards is strictly voluntary, 
decided among trading partners. 

• The standards specify only the format, rules, and data 
content of electronic business transactions; they do not 
address how trading partners will establish the required 
physical communications link to exchange EDI data. 

To take advantage of emerging electronic information 
technology capabilities, the Department of Defense has adopted 
the concept of Electronic Commerce (EC), the digital exchange 
of all information needed to conduct business. The objective 
of DoD's EC program is not to just automate existing manual 
processes, but to implement the necessary systems, 
capabilities, and procedures which will allow DoD activities 
to fundamentally alter and improve the manner in which they 
accomplish their business operations. Although EC encompasses 
a variety of electronic information processing technologies, 
the key to DoD changing its business practices from paper- 
based document processing to a total electronic environment is 
electronic data interchange. 
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Recognizing the potential of EDI, the Deputy Secretary of 
Defense, in May of 1988, issued a memorandum specifying that 
EDI was to "become the way of doing business" for the 
Department of Defense. Specifically, Deputy Secretary Taft 
directed that: [Ref. 15] 

Consistent with our commitments to improve productivity 
and move toward a paperless environment, all DoD 
components should make maximum use of electronic data 
interchange (EDI) for the paperless processing of all 
business-related transactions. 

The American National Standards Institute X12 uniform 
standards for inter-industry electronic interchange of 
business transactions will be employed as the standard for 
EDI, providing a common approach to implementation and a 
single, coordinated DoD position to industry. 

The Department of Defense's commitment to EDI was further 
established in November 1990, with the Deputy Secretary of 
Defense approval of the Defense Management Report Decision 
(DMRD) 941, which directed the development, implementation, 
and management of a standard DoD EDI system. As part of the 
move to a "paperless" environment, DMRD 941 identified 16 
forms and documents as "key EDI candidates," initiating their 
replacement with their electronic equivalents. 

Defense transportation was one of the four functional 
areas identified by DMRD 941 as having the potential for 
significant savings and efficiency improvements resulting from 
the application of EDI technology. Through the electronic 
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exchange of information among ics trading partners, 19 DoD 
hopes to achieve increased economies and efficiencies in 
defense transportation operations. DoD's implementation of 
EDI in defense transportation involves a systems approach, 
integrating several functional area application processes and 
the individual transaction sets used to facilitate the 
electronic exchange of information. The comprehensive nature 
of DoD's approach to the implementation of EDI in defense 
transportation is summarized in two predominant operating 
concepts: 1) Defense Transportation EDI Operating 
Concept—Freight and 2) Defense Transportation EDI Operating 
Concept—Personal Property. 

Reflecting the long-term commitment to EDI, DoD efforts 
are continually expanding the bounds of EDI implementation. 
Four of the principal future enhancements for defense 
transportation include: 1) Defense Transportation Payment 
System, 2) Electronic Funds Transfer, 3) Transaction Set 820, 
Payment Order/Remittance Advice, and 4) Electronic Submission 
of Guaranteed Traffic Tenders. 

In addition to the specific EDI projects which are an 
integral part of the overall defense transportation EDI 
operating concept (e.g., CFM, TOPS, and WHIST), there are 


19 The Department of Defense's trading partners for the 
electronic exchange of information pertaining to defense 
transportation operations include: DoD shipping activities, the 
Military Traffic Management Command (MTMC) , the Defense Finance and 
Accounting Service, Indianapolis Center (DFAS-IN), the General 
Services Administration (GSA), and commercial carriers. 
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numerous other initiatives underway. These efforts include 
projects designed to interface with the freight and personal 
property EDI operating concepts as well as those which are 
more service specific in nature. 

B. CONCLUSIONS 

The Department of Defense is no longer concerned with the 
question of "Should we adopt EDI technology?" The commitment 
to EDI exists and the focus now is on "How best do we 
implement this technology to maximize the return on 
investment?" 

Although the goal of achieving a "paperless" environment 
may suggest that the primary benefit of EDI implementation is 
strictly that of paperwork reduction/elimination, this is not 
the case. As DoD continues in its EDI implementation efforts, 
it is becoming more evident that the actual benefits of EDI 
extend beyond the simple reduction/elimination of paper. 
While the actual realized benefits of EDI implementation will 
be situationally dependent, the use of electronic (vice paper- 
based) systems is consistently resulting in more efficient and 
effective ways to conduct business transactions. DoD business 
relationships utilizing EDI for conducting transactions among 
trading partners result in operating improvements and benefits 
including: 

• Reduced paper handling and storage costs. EDI eliminates, 
or reduces, the volume of paperwork required to conduct 
many standard business transactions. With this paperwork 
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reduction comes a corresponding reduction in the costs 
associated with the personnel and equipment required to 
manually process and subsequently store paper-based 
transactions. 

• Increased Accuracy. Most traditional, paper-based 
information processing methods are characterized by a data 
entry/re-entry cycle in which the same data is entered and 
re-entered numerous times. EDI eliminates this re¬ 
entering of data by exchanging data directly between 
computer systems. This direct exchange of data reduces 
the possibility of data errors which can result from 
repeated "handling" and human intervention. 

• Timeliness of Data. With non-EDI information processing 

systems, the process of exchanging data is often slow, 
resulting from a reliance on mail, courier service, 
facsimile machines, or even telephone. EDI dramatically 
decreases the time spent exchanging data between users by 
the virtually instantaneous, computer-to-computer, 

transmission of information electronically. 


The implementation of electronic data interchange 
represents a significant change in the traditional way the 
Department of Defense conducts business. Although the results 
of this research do reflect the significant potential benefits 
of DoD EDI implementation efforts, it has also identified 
areas of potential resistance to the change. Barriers to the 
efficient implementation of EDI must be resolved before DoD 
can realize the full benefits of conducting business 
electronically. These barriers include: 

• Lack of knowledge and/or understanding of the capabilities 
and limitations of EDI. 

• Decentralization among individual services which has 
resulted in duplication of effort and the corresponding 
expenditure of additional scarce resources. 

• Potential problems associated with cost-benefit analysis 
and resourcing decisions due to difficulties m 
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identifying and quantifying actual cost relaced savings 
resulting from EDI implementation. 

• Ensuring coordination among trading partners concerning 
the standardization of data mapping and implementation 
conventions. These activities are key to unlocking EDI's 
potential for improving che effectiveness of electronic 
incerorganizational communication. Without these, EDI is 
nothing more than a communications method which may or may 
not result in the efficient exchange of information among 
trading partners. 

The implementation of electronic data interchange involves 
much more than simply automating standard business documents 
and existing business processes. To realize the full 
potential of EDI, organizations must review the way they 
currently conduct business. Those involved with EDI need to 
realize that electronic data interchange is a technology, a 
"way of doing things," and not a specific or individual 
system. As such, it has the potential for application to many 
different processes currently in use. 

The proper implementation of EDI can be a catalyst, 
streamlining inefficient, redundant, and outdated business 
practices, resulting in the ability to conduct business 
faster, more accurately, and at a lower cost than the 
traditional manual paper-based information processing systems. 

C. RESEARCH QUESTIONS 

The primary objective of this research was to examine the 
following question: 
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What actions have been taken to implement Electronic Data 
Interchange with Department of Defense transportation 
operations? 

To answer this basic research question, the following 
subsidiary questions were addressed: 

• What are the essential elements of EDI? 

The essential elements of EDI consist of: EDI standards, 
EDI software, the EDI platform (i.e., hardware configuration), 
and the communications linkages. Chapter III (EDI standards) 
and Chapter IV (EDI software, hardware, and communications) go 
into specific detail concerning the integration of these 
resources and the subsequent EDI communications capability. 

• What has been the Department of Defense's approach to the 
implementation of EDI technology? 

The Department of Defense is committed to the 
implementation of electronic data interchange and has embraced 
EDI as the predominant means for achieving Electronic 
Commerce. DoD's approach to EDI includes implementation with 
four functional areas: 1) Procurement and Contract 

Administration, 2) Transportation, 3) Supply and Maintenance, 
and 4) Fuels. As discussed in Chapter V, this commitment is 
officially endorsed by such policy initiatives as the Deputy 
Secretary of Defense's memorandum of May 1988 and the Defense 
Management Report Decision 941. 

• What benefits may be realized from DoD's EDI 

implementation with defense transportation operations? 

As with most EDI implementations, the benefits which DoD 

receives from utilizing EDI in defense transportation 
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operations consist primarily of reductions in paper handling 
and storage costs as well as increases in the accuracy and 
timeliness of data. Chapters II and V address benefits 
related to the application of EDI technology to information 
handling processes. Chapter II presents a generalized 
discussion focusing on benefits typically experienced with EDI 
use, while Chapter V specifically addresses the direct and 
indirect benefits (cost savings) which DoD expects as a result 
of their EDI implementation efforts. 

• What are the specific areas in which EDI has been applied 
to DoD transportation? 

Chapter VI covers this area in great detail. Primarily, 
in defense transportation, EDI has been implemented in the 
areas of shipment information (i.e., GBL) and vendor payment 
related areas (e.g., tenders and invoices). 

• What are the proposed defense transportation EDI 
application areas? 

This is discussed in Chapter VI, Future/Proposed 
Enhancements, and includes 1) Defense Transportation Payment 
System, 2) electronic funds transfer, 3) Transaction set 820, 
Payment Order/Remittance Advice, and 4) electronic submission 
of guaranteed traffic tenders. 

• What, if any, barriers exist to the optimal implementation 
of EDI? 

As discussed in Chapter VI, the barriers to the efficient 
implementation of EDI include 1) lack of knowledge and/or 
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understanding, 2) decentralization of effort, 3) cost-benefit 
analysis and resourcing, and 4! standardization. 











APPENDIX A 




LIST OF ACRONYMS 

AMC 

= 

Air Mobility Command 

ANSI 

SK 

American National Standards Institute 

ASC X12 

= 

Accredited Standards Committee X12 

ASD(PfcL) 

3 

Assistant Secretary of Defense (Production and 



Logistics) 

CFM 

= 

CONUS Freight Management 

CFR 

= 

Code of Federal Regulations 

CMOS 


Cargo Movement Operations System 

CONUS 

= 

Continental United States 

CRAF 

» 

Civil Reserve Air Fleet 

CSL 

3E 

Computer Systems Laboratory 

DDN 

» 

Defense Data Network 

DEALS 

= 

Do-It-Yourself Electronic Data Interchange 



Automated Loading System 

DES 

= 

Data Encryption Standard 

DFAS-IN 

= 

Defense Finance and Accounting Service 



Indianapolis Center 

DISA 

= 

Data Interchange Standards Association, Inc. 

DITY 

= 

Do-It-Yourself 

DLA 

- 

Defense Logistics Agency 

DMRD 

= 

Defense Management Report Decision 

DoD 

. 

Department of Defense 
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DTRS 


DTTS 

EA 

EC 

EDI 

ED I FACT 

EFT 

FIPS 

GBL 

GSA 

GTN 

HEAT 

IBS 

ITV 

JCS 

LMI 

MAC 

MSC 

MTMC 

MTMC-CF 

MTMC-IN 

MTPP 

NAVMTO 


Defense Transportation Payment System 
Defense Transportation Tracking System 
Executive Agent 
Electronic Commerce 
Electronic Data Interchange 

United Nations/EDI for Administration, 

Commerce, and Transport 

Electronic Funds Transfer 

Federal Information Processing Standard 

Government Bill of Lading 

General Services Administration 

Global Transportation Network 

Household Goods Electronic Data Interchange 

Automated Transactions 

Integrated Booking System 

In-Transit Visibility 

Joint Chiefs of Staff 

Logistics Management Institute 

Message Authentication Code 

Military Sealift Command 

Military Traffic Management Command 

Deputy Chief of Staff for Information 

Management - CONUS Freight 

MTMC Inland Traffic Directorate 

MTMC Personal Property Directorate 

Navy Material Transportation Office 
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NFAF 

- 

Naval Fleec Auxiliary Force 

NLN 

* 

NAVSUP Logistics Network 

PPSO 

3 

Personal Property Shipping Office 

PRB 

3 

Procedures Review Board 

RRF 

« 

Ready Reserve Force 

TCC 

- 

Transportation Component Command 

TDCC 

3 

Transportation Data Coordinating Committee 

TMS 

3 

Transportation Management System 

TOPS 

* 

Transportation Operational Personal Property 

Standard System 

TPA 


Trading Partner Agreement 

TVCB 

- 

Transportation Voucher Certification Branch 

UCS 

as 

Uniform Communication Standard 

USTRANSCOM 

m 

United States Transportation Command 

VAN 

= 

Value Added Network 

WHIST 

ss 

Worldwide Household Goods Information System 

for Transportation 

WINS 

- 

Warehouse Information Network 

WPS 


Worldwide Port System 
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APPENDIX B 


DMRD 941 DOCUMENTS BY OPPORTUNITY AREA 
PROCUREMENT/CONTRACT ADMINISTRATION 

DD Form 250 - Material Inspection and Receiving Report. 

The DD Form 250 is a multiple purpose document. It is 
primarily used for inspection, acceptance, and receiving 
of materials from a contractor, but is also used as an 
invoice if a contractor chooses. It has a standard 
distribution: to the consignee, the contract 

administration office, the purchasing office, and the 
payment office. ANSI transaction sets 810, 856, 861, and 
863 could be substituted for the DD Form 250. 

SF 1443 - Contractor's Request for Progress Payments. The 
General Services Administration Standard Form (SF) 1443 is 
used by contractors to request progress payments from DoD. 
Progress payments are usually made on a regular and 
continual basis. The request for payment and the actual 
payment process itself could be accomplished by electronic 
funds transfer (EFT). ANSI transaction sets 810 and 820 
are ideal for this application. 

SF 30 - Amendment of Solicitation/Contract Modification. 
The SF 30 is used to modify contracts, orders, or 
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solicitations. Contractors receive the form and use it to 
adjust their internal proposal preparation and 
contract/order management systems. EDI transmission of 
this document will permit better visibility over contract 
details and improve the ability to track contract line 
items, unit prices, delivery schedules, engineering 
changes, and amended shipping instructions. ANSI 
transaction sets 850 and 860 may apply to portions of the 
SF 30. 

SF 18 - Request for Quotations. Although the SF 18 is 
principally a paper document, DoD executes as much as 50 
percent of its requests for quotations by telephone. The 
SF 18 is used by prospective DoD suppliers, who complete 
the unit price and certification sections and then return 
the form to DoD. ANSI transaction sets 840 and 843 are 
designed for requesting and sending quotations 
electronically. 

SF 129 - Solicitation Mailing List Application. The SF 
129 allows prospective vendors to enroll in the buying 
agency's automated bidders' mailing list system. It is 
completed by the vendor and mailed to the buying office 
where it is reviewed and entered into an automated mailing 
list. The SF 129 is an excellent candidate for EDI, in 
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pare because the Office of Federal Procurement Policy 
wants to develop a national bidders list. 


DD Form 1155 - Order for Supplies and Services. 

Functioning as either a purchase order for small purchases 
(less than $25,000) or delivery orders for indefinite 
delivery contracts, DD Form 1155 is one of the most 
pervasive forms in DoD. The ANSI transaction set 850 is 
well suited for transmitting DD Form 1155 information. 


TRANSPORTATION 

SF 1103 - Freight GBL ; CBLj SF 1113 - Public Voucher. 
These documents are used by DoD to procure freight 
transportation and related services from commercial 
carriers. The SF 1103 (freight Government bill of 
lading), used to procure non-local service, is a seven- 
part document distributed to the carrier, shipper, 
consignee, Military Traffic Management Command (WTMC) , and 
finance center. The CBL (commercial bill of lading) is 
used to procure local small package services. Carriers 
submit the SF 1113 to the finance center as an invoice. 
The ANSI transaction sets 820 and 858 could accommodate 
these documents. 
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SP 1203 - Personal Property GBL; 619/619-1 - Statement of 


Accessorial Services Performed ; and SF 1113 - Public 
Voucher. These documents are used by DoD to procure 
personal property transportation and related services from 
commercial carriers. The SF 1203 is a seven-part document 
distributed to the carrier, shipping office, receiving 
office, MTMC, and finance center. The 619 and 619-1, 
which are used to confirm the performance of additional 
personal property services, must be submitted along with 
the SF 1113 for payment to the finance center. The ANSI 
transaction sets 820 and 858 are suitable for these 
documents. 

SF 1169 - Government Travel Request; SF 1113 - Public 
Voucher. These documents are used by DoD to procure 
travel services. The SF 1169 is distributed to the 
finance center by the passenger carrier along with an SF 
1113 for payment. The ANSI transaction sets 820 and 858 
could be applied to these documents. 

Voucher Stub and Check. These documents are used to pay 
carriers for transportation-related services. The check 
is produced by the finance center, combined with the stub 
from the public voucher (SF 1113), and then mailed to the 
carrier. The voucher stub serves as the carrier's 
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remittance advice. The ANSI transaction set 820 is 
suitable for these documents. 

KT 364R - Standard Tender. The tender specifies the 
freight rates under which carriers propose to move DoD 
cargo. It provides information for transportation 
pricing, carrier selection, auditing, and payment. 
Carriers must submit nine copies to MTMC for processing. 
MTMC distributes copies of the tender to its Eastern and 
Western Area Commands, the General Services 
Administration, Navy Material Transportation Office, and 
to the carrier. The ANSI transaction set 602 has been 
created to replace this document. 

SUPPLY/MAINTENANCE 

SP 364 - Report of Discrepancy (Supply). The SF 364, 
administered by the Defense Logistics Standard Systems 
Division, reports shipment conditions such as incorrect 
quantity, improper labelling, or poor conditions. It is 
sent to the DoD item manager or an item manager from an 
affiliated civil agency, such as the General Services 
Administration. 

SAV 926 - Itonthly Report, Receipt of RepairaJoles . The SAV 
(Standard Aviation Systems Command) 926, an Army document, 
is generated monthly by commercial maintenance activities 
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to notify inventory control points of the quantity and 
status of unserviceable assets sent to them for repair. 
The other Military Services use forms comparable to the 
SAV 926. 

SP 368 - Product Quality Deficiency Report. The SF 368 is 
administered by the Defense Logistics Agency and reports 
material defects stemming from the original manufacturer. 
The SF 368 may require product analysis or testing by 
laboratories and contact with the vendor. Like the SF 
364, it is sent to the DoD item manager or an item manager 
from an affiliated civil agency. 

SP 361 - Transportation Discrepancy Report. The SF 361, 
administered by MTMC, is used to report conditions such as 
damage to the material while intransit or delivery to the 
wrong recipient. It is generally sent to the appropriate 
MTMC area command, and to the ultimate consignee if it is 
issued by an intermediate receiver. A copy is also sent 
to the commercial carrier if one is involved. 

FUELS 

DD Form 1898 - Aviation Fuels Sales Slip. The DD Form 
1898, an aviation fuel sales slip or "delivery ticket," is 
used to document that the aviation fuel invoiced for 
payment on an into-plane invoice was actually delivered to 
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a Government activity. DD Form 1898 mto-plane receipts 
are signed by the pilot, who retains a copy. The fuel 
company sends another copy of the delivery ticket with its 
into-plane invoice to the Defense Fuels Supply Center for 
payment. If the hardcopy DD Form 1898 has valid nameplate 
information and is signed by a Government representative, 
then the Defense Fuels Supply Center certifies the invoice 
for payment. ANSI transactions sets 810 and 856 can be 
used to replace the DD Form 1898 and commercial invoice. 
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